Feature request: function to reset internal GL state tracking
Is your feature request related to a problem? Please describe. In our project we're mixing Filament rendering with an external OpenGL-based renderer that handles the 2D UI. On non-web platforms we use shared contexts and everything works great. On the web though, there's no option to do this. This means we sometimes run into conflicts with Filament due to its internal state tracking. It shows up in unexpected ways - like textures not getting bound correctly, or wrong sampler settings getting applied - and always takes a bit to track down.
Describe the solution you'd like
I'd like a function to reset the internal state tracking. Something like Engine::resetStateTracking(), that we could call once a frame. On non-GL platforms (and maybe even on everything but WebGL specifically) it'd be a no-op.
Describe alternatives you've considered
Currently we reset state to valid defaults after the external GL library renders, but that is only a partial workaround. We've considered using glGet, but it's too slow.
OS and backend Yes, this is GL-specific, as none of the other APIs have global state.
This is something I'd be happy to submit a PR for if it's likely to be accepted.
I'm very reluctant adding such an API because we're not actually tracking all the state that might exist. To implement this correctly, we would have to:
- reset the state we track
- reset the state we set during init (i.e. constant state)
- reset the state we don't know we rely on (like all the GL defaults)
- reset the state we don't know about (i.e. you could change some extension state we're not using) but that has an impact on rendering or on our state.
This is also a lot of tedious work we don't need ourselves, so I think the best course of action would be to submit a PR adding this feature and we'll review it.
I think solving just the first one is at least a good start. We're already able to solve any problems caused by 2-4, but due to how the state tracking works (and the lack of ability to introspect it), there's often no guaranteed way to work around bugs caused by the state tracking itself.
Would a PR just doing (1) have a chance? Or should I do 1-3? (4) seems like it's out of scope.
Yes a PR just doing (1) would have a chance.
Resolved via #6105