Mixing with raw openGL calls and Context::current().resetState() about magnum

[mosra]

I get a crash after a frame (or 2?) when imgui is draw with the Mesh object.

To explain this behavior, the state tracker at that point thinks the Mesh object VAO was still bound, while in reality you called glBindVertexArray(0) in the meantime. And GL has this great misfeature where it interprets the buffer offsets as pointers into client memory if no vertex buffer is bound, leading to a null pointer dereference and crash. That's the extreme scenario and the resetState() tells the state tracker that it shouldn't assume a particular VAO is bound and instead bind it again.

In general I should be able to bind different gl buffers / textures as long as I use resetState() right to push/pop my changes?

Yes. Buffers, textures, framebuffers, VAOs, currently used shaders, transform feedback. That all is tracked (and the tracked state is reset by this call). However note that the reset isn't resetting the state itself -- that'd be too slow -- it's just resetting the tracker. In other words it causes Magnum to explicitly rebind/reset a particular state next time it gets used, but until then GL isn't touched in any way.

corruption of the framebuffer with imgui or something

The state reset in this cause leads to the state tracker thinking no known framebuffer is bound (so, not even the default one). Which then unfortunately leads to the GL::defaultFramebuffer.setViewport() call in viewportEvent() in that example not being propagated to a glViewport() call, because it's not sure that GL::defaultFramebuffer is currently bound. Calling

GL::Context::current().resetState(GL::Context::State::EnterExternal);
GL::Context::current().resetState(GL::Context::State::ExitExternal);
GL::defaultFramebuffer.bind();

"fixes" this, calling the resetState() before the clear() also fixes it. You could also exclude framebuffer-related state from these if you aren't touching them in any way in the raw GL calls, which fixes that too:

GL::Context::current().resetState(GL::Context::State::EnterExternal & ~GL::Context::State::Framebuffer);
GL::Context::current().resetState(GL::Context::State::ExitExternal & ~GL::Context::State::Framebuffer);

Honestly, I'm not sure what would be the best way to handle this problem inside Magnum, apart from completely ditching the design where Magnum pretends a viewport rect is framebuffer-local state (which in reality it isn't).

[TrevorCash]

Thanks, I think I understand the behalviour better.

Initially I expected that State::EnterExternal and State::ExitExternal would do a full push/pop. and State::ExitExternal would make the tracker think that the default framebuffer is bound again (or whatever state it was in at State::EnterExternal time). (which in my use case it still would be bound because I did not alter that).

[mosra]

would make the tracker think that the default framebuffer is bound again (or whatever state it was in at State::EnterExternal time)

Yes, that's where the problem is. There's about sixty thousand state variables, recording all of them and setting them back to the previous would be extremely costly :/ Instead, the state tracker just resets its internal assumptions -- and expects the "external" code to also not have any assumptions about any state either -- which isn't great from an encapsulation perspective as it leads to corner cases like this, but doesn't cause perf problems.

I'll think of this a bit more, maybe the bound framebuffer is a special enough state (due to how setViewport() works, and due to how the default framebuffer works) that it may be worth to save and restore it.