Global OpenGL state

[elect86]

globjects poses a very interesting matter about the opengl state

From their readme

"
State

OpenGL state is wrapped as States, StateSettings and Capabilities, where the latter two are mainly used internally.

auto currentState = State::currentState(); // full current state; usable for resetting

auto state1 = new State(State::ImmediateMode); // all changes are applied immediately
state1->enable(GL_RASTERIZER_DISCARD); // Configuring a Capability
state1->primitiveRestartIndex(static_cast<GLuint>(-1)); // Configuring a StateSetting

auto state2 = new State(State::DeferredMode); // changes has to be applied explicitly
state2->pointSize(10.0f);
state2->apply();

currentState->apply(); // Reset manipulated state

I like the idea to have a determined place where we can set important variables. In the sample he uses ImmediateMode, but I'm thinking more about using DSA (Direct State Access) or not. Atm DSA is just a top variable to say..

Also, sometimes, for debug purposes, I always missed a confortable way to reset the whole current gl state in a specific point.

Having something like state::reset looks wonderful under this point of view..

[Sylvyrfysh]

That's expensive to do (getting, and then resetting). I don't see where you think this will matter for DSA

[Wasabi375]

I agree with Nick. Most of the time you don't care about resetting the state as you have to set up the entire state anyways when doing anything.
I like the idea of a function that does a full reset though. This could be amazing for debugging and finding areas where you depend on previously set state that you don't know about. We could simply implement a function setting the default values.

As for setting and restoring state, you can use glPushAttrib and glPopAttrib to do that. I have never used it (just saw it in the documentation containing the defaults).

[elect86]

That's expensive to do (getting, and then resetting). I don't see where you think this will matter for DSA

Yeah, you are totally right, but as I said it'd be only for debug purposes (I swear :D)

About DSA, it's a way to say to gln to use DSA version or not whenever we have to retrieve/set identifiers parameters

Like, at the start, you check if you have DSA and then you set it

gl.state.dsa = caps.extensions.ARB_direct_state_access

As for setting and restoring state, you can use glPushAttrib and glPopAttrib to do that. I have never used it (just saw it in the documentation containing the defaults).

I don't recall that function going through all the core gl classes, and indeed it looks it's deprecated

One cool features to have, I thought about, is also a function that will print out in console (or some other smarter way) all the states which are not default, that is all those who are currently affected by your code till that point.

[elect86]

Regarding the state, it's also the perfect place to hold internal opengl state variables, such as _cullFaceEnabled (code), _logicOpEnabled, etc

[Sylvyrfysh]

Maybe something like this? I see what you mean with the things in gl11, but this option only adds runtime overhead to those that request it

[Sylvyrfysh]

https://gist.github.com/Sylvyrfysh/e88b7b785396f88db036a1c84858aa77

[Sylvyrfysh]

That could be modified to hold variables, but keep the tracking enabled/disabled part. Thoughts?

[Sylvyrfysh]

https://gist.github.com/Sylvyrfysh/10e881035f79a5ea538328da4084a4e2

Updated idea

[elect86]

it looks overkill for me, but I feel the idea has a lot of potential though.

Let's keep this in the air for further updates

[Sylvyrfysh]

thoughts on https://gist.github.com/Sylvyrfysh/ed8297d9680f90844df079541359d9d7 ? dsa like, that could be a use case

[elect86]

The DSA looks also interesting indeed.

Honestly I always thought (and implemented so far) only the arb one. But we could support also the ext one.

Ps: what's the FULL dsa?

[Sylvyrfysh]

Just plain GL45 dsa calls. Since that's when it became core

[Sylvyrfysh]

Thoughts on the two last commits at https://github.com/kotlin-graphics/gln/commits/more-state ? The framebuffer one might be overreaching, but I thought that you guys might have different ideas on what should be tracked. The first commit is the more important one, as it explicitly tracks what the last logicop and cullface were set to. This would be a negative if the user is using an external library that does not use GLN, as it no longer queries the GL as to what is actually active.

[elect86]

The framebuffer one might indeed be overreaching, but we can leave it as it is until we reach some more firm point, it won't hurt.

The logicOp and cullFace is instead more important and useful, querying the state on the java client side is definitely much faster than querying gl, everything happens under the jvm (included optimization), no native call involved.

To avoid confusion/problems with the user using an external library, this shall be definitely mentioned in the manual, feel free to modify it. I still didnt care for a clean struct atm, it's still highly wip