You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a use case where I want to render to a texture for later use, but I don't need the fbo object to stick around. Since dispose also wipes the texture, I've been doing this:
This allows me to keep the texture object and still call dispose on the fbo, but is a little hacky. Is there a better pattern for this? If not, what would an acceptable API for this behavior be? Something like the following?
Another way to do it would be to inject the texture via an argument, though it might take a bit more work to set up and then you have to track the texture as a dependency. The advantage there though is that it is closer to how WebGL actually works and it would let you reuse the same texture across multiple FBOs.
That said, I think the dispose() modification seems reasonable. If you want to write a PR, go for it and I'll merge it in. It is probably less work up front and doesn't really break anything existing.
Those are great points. I'm wondering now if a better approach might be to make a new fbo module that expects a texture, and then convert this module into a wrapper around it that still matches this module's behavior. Seems like it might make the internal logic easier, and still leaves users with an easy-to-comprehend module here.
I have a use case where I want to render to a texture for later use, but I don't need the fbo object to stick around. Since
dispose
also wipes the texture, I've been doing this:This allows me to keep the texture object and still call dispose on the fbo, but is a little hacky. Is there a better pattern for this? If not, what would an acceptable API for this behavior be? Something like the following?
I'm happy to make a PR if we can find consensus.
The text was updated successfully, but these errors were encountered: