Open X-Ryl669 opened 7 years ago
You're right, a fine-grained handling of states would be best. We actually had plans to create state-stacks from which you can push and pop that would compute the actual difference for restoring the state (https://github.com/cginternals/globjects/pull/149).
However, to compute differences we have to know the ground-truth and that is what globjects::State::currentState
is about.
I assume you use a core profile, so polygon modes are disabled?
However, to compute differences we have to know the ground-truth and that is what globjects::State::currentState is about.
Not necessarly. It depends where you want to pay the cost for state tracking. Either you pay the cost on first use (that is, you need to search for a state change in your state's stack and if not found, you'll have to query the driver for the "current" state's value), or on initialization (like the currentState
does). For the fastest state changing, the latter is best, since you bootstrap from a known state (and as such, state change will be 1:1 to what's done with standard gl-func based coding). The former is more intuitive through, since you don't care about having to deal with a currentState
anymore.
In general case however, if you expect some state, you should set it (and not rely on whatever driver's default value that could be modified by any library used), so maybe an hybrid approach would be better where you can create a "default" state stack value, you can restore anytime. This would avoid the need to searching the previous state every time you change a state.
Yes, I'm using a core profile.
This code:
Trigger this GL error:
The backtrace for this error is:
Clearly, it's dealing with polygon mode which I've not touched in my code. I wonder if the "currentState" is a good idea at all. It's slow (because it loops other all states to restore them). I wonder if a per-thread storage list of modified state wouldn't be better. That is, any state changed with a State instance would append the previous state to a TLS's list (if it's not found in the list beforehand, obviously), and a static restoreState() would pop all item from the TLS's list to restore all the current modified state and not all the states like it's done currently, thus avoiding the error written above.