What is the point? In slick2d, you have the Graphics object, and it seems to just draw lines… And I was recently told that any good engine makes graphics abstract. So what is up with that? Why even make a graphics object?!
I’m no expert, but I believe that making changes to the graphics context state can be an expensive operation in some rendering pipelines.
Encapsulating the graphics context allows for more precise caching of operations thereby minimising state changes.
I’ll agree with what Abuse said. By building a graphics class to manage rendering settings, then you can majorly decrease gl calls and resource usage. And maybe take a look at Slick’s Graphics class. There is quite a bit more going on than “just drawing lines”.
Just a guess, but its just a way to access the low level rendering capabilities of a library. You can essentially create a new context anywhere in your code, where if you didn’t have contexts… Well I don’t know how you would handle rendering because you couldn’t create a new instance of the rendering handler. The other thing is that when you create a new thread, you need to create a new context for that thread, so without contexts, you couldn’t do much on separate threads. Again, just a guess because I’ve never researched it.
It’s all just lingo, mate. Call it what you want. The premise is that you have something to render your graphics, instead of re-inventing the wheel everytime you need something on the screen. So, yes, successful engines are successful due in part that they can draw graphics.
It is more that just that. The graphics context is an interface used to hide the underlying implementation. So you can start with LWJGL. Then you can add JOGL later and the user of your library can easily switch.