Return to Answer

That does require a bit more thought and collaboration upfront about the rendering needs of particular objects you anticipate upfront as well as possibly data structures which organize and group such things based on identical state requirements. But if you can structure your software like this, then I think that leads to the ideal balance of both a performant solution and minimal state (mis)management. There's also considerably less state to manage in the first place the further you move away from the fixed pipeline (if you haven't already).

The first couple of statements don't compute for me. Any singletons with state are global state, so unless they're stateless and can't be mutated, I don't see why on earth anyone against global state would happily introduce more singletons into the mix. Parameter passing makes sense to me as an alternative to globals.

That does require a bit more thought and collaboration upfront about the rendering needs of particular objects you anticipate upfront as well as possibly data structures which organize and group such things based on identical state requirements. But if you can structure your software like this, then I think that leads to the ideal balance of both a performant solution and minimal state (mis)management. There's also considerably less global state to manage in the first place the further you move away from the fixed pipeline (if you haven't already).

The first couple of statements don't compute for me. Any singletons with state are global state, so unless they're stateless and can't be mutated, I don't see why on earth anyone against global state would happily introduce more singletons into the mix. Parameter passing and DI makes sense to me as an alternative to globals.

And it's not the prettiest but once that object went out of scope, the line width would be set back to 1. And they did that for all the relevant GL states the fixed pipeline was fiddling with, and that made the codebase a lot more predictable in terms of what sort of state you could expect when writing new code and also having any state changes it made be reverted when exiting the function (either normally or as the result of an exception).

You could also alternatively use glGet* and capture the state in the constructor and restore the previous state in the destructor (that would probably be more robust, especially in nested cases), but I think my colleagues chose to design it that way as a way to try to force the system to constantly be in some default state (ex: always being able to expect the line width to be 1 for wireframe rendering unless very temporarily set otherwise).

And it's not the prettiest but once that object went out of scope, the line width would be set back to 1. And they did that for all the relevant GL states the fixed pipeline was fiddling with, and that made the codebase a lot more predictable in terms of what sort of state you could expect when writing new code and also having any state changes it made be reverted when exiting the function (either normally or as the result of an exception).

struct GlLineWidth { GlLineWidth(float new_width) {glLineWidth(new_width);} ~GlLineWidth() {glLineWidth(1.0f);} }; 

struct GlLineWidth: noncopyble { GlLineWidth(float new_width) {glLineWidth(new_width);} ~GlLineWidth() {glLineWidth(1.0f);} };