Backends: OpenGL3: Add support for independent draw buffers blend

[oleglatin]

Starting since OpenGL 3.0 user can enable/disable blending for each draw buffer separately and since OpenGL 4.0 user can specify different blending parameters or equations for each draw buffer.

ImGUI currently uses non-indexed functions to setup blending and it may corrupt engine state.

Fix that by using indexed functions.

[ocornut]

Thanks for the PR. I first need to give you special credit as this looks GOOD and in line with local coding style (and unfortunately it isn't that common) :)

and it may corrupt engine state.

In theory this is all good and desirable. But I have an issue with the fact that the number of GL states is potentially enormous and we're trying to find to find the right balance between making the backend helpful while keeping it reasonably readable.

My guess, and let me know if I am wrong, is that non-trivial engines are generally not relying on global GL state being preserved across frames, they would generally set the things they need to setup a draw call. Based on this, in seems like the generous "tries to backup and restore all states" stance of backend, which is mostly designed to help the hello-first-triangle crowd, isn't so useful in the context of more advanced GL state functions? Did you actually encounter problems in your application that needs this patch in the imgui_impl_opengl backend?

[oleglatin]

Actually I'm not really sure how production engines manages an GL states :)

In my app all state changes are passed through a state cache to avoid any unnecessary driver calls. Also in "hard opengl debug mode" I have a state validator which just construct state object by querying current GL state and comparing it with cached values. After ImGui setup validator starts throwing exceptions due to state mismatch. That's how this patch was appeared.

Just I though that the purpose of backend is to "try to backup and restore all states" that why I tried to fix it. I agree that GL have a lot of states and keeping it consistent across all possible GL and GLES version is not trivial thing. If you'd like to keep backend simple I'm OK with that. I'm sure I can workaround it in my app. Just maybe patch can be useful for other folks :)

[sturnclaw]

It may not be a AAA production engine, but on Pioneer Space Sim before we converted the ImGui render backend to use our own render API we'd simply flush the GL state cache after running the ImGui render backend. Reconfiguring most of the GL state that ImGui actually touches is pretty cheap to do at the beginning of the next frame, and it avoids issues with ImGui modifying GL state that the state cache doesn't know about.

In general though, most modern APIs are moving to a pipeline-state-object design which wraps all associated render state; OpenGL state is usually downstream of that inside the render backend and manipulated as needed based on the PSO associated with the current draw call. This also avoids the (sometimes extremely significant depending on driver) overhead of using glGet as part of regular draw commands.