View Full Version : The case for OpenGL - are OpenGL ES and its derivatives still necessary today?

02-02-2017, 05:35 AM

It's been a while, so first off, hello everyone!

We don't seem to have a sub-forum for higher-level discussions of the big picture, i.e. not only the OpenGL spec but also the whole ecosystem. Please move this accordingly of another place is more suitable.

Warning: This question may incur TL/DR syndrome.


I currently find myself in the position to revamp a tighly integrated, C++- and OpenGL-based, specialized renderer under the hood of a specialized product. In addition, other renderers exist to cater to other targets. The ultimate goal is to have once code base to rule them all and get rid of all unnecessery duplicates which are a nightmare to maintain and improve. More to the point: we strive for code written and tested in C++, either compiled directly for the target platform (Windows, iOS) or transpiled with emscripten or (in the future) compiled directly to WebAssembly. Before you ask: Unity or the Unreal Engine are deliberately out of the picture for various reasons.

Since our targets currently are desktops(Windows, x86[_64]), iOS and (increasingly) cloud-backed Web applications leveraging WebGL as the rendering backend, I have a lot to think about on how to make this right. My research and my relatively substantial experience as a desktop GL affine graphics developer brings me to somewhat troubling contemplation.


Everytime I think about OpenGL ES and derivatives like WebGL, I wonder what the respective rationale behind their conception was and whether it still holds today. As a desktop OpenGL developer, having valuable features taken from me when moving to mobile platforms is not only somewhat of a kick in the pants, it complicates matters with the inherent necessity to support different rendering paths.

In constrained and highly sensitive environments like airplanes, medical equipment and possibly military applications, reducing the complexity of the specification is one way of allowing for simpler implementations which are less error-prone, maybe easier to verify and ultimately to certify. For the above mentioned applications and reasons, something like the OpenGL SC profile makes a lot of sense to me, even today. At the time, it also made sense to me to provide a subset for mobile hardware not sophisticated enough to support everything desktop hardware could offer. In an age, however, where mobile and desktop environments converge to supporting powerful APIs like Vulkan, the approach of maintaining three different specifications (and even furthering them like, WebGL2) which have a lot of inherent similarities anyway is a little beyond me.

On web platforms we have WebGL, which, from my point of view, is hopelessly outdated and it would not be feasible to even bother, were it not for the fact that it's the only stable and plug-in free option I know of for rendering inside a browser. It's been more than 3 years since the initial draft for WebGL2 and as far as I can see, the spec has still not been ratified, albeit implementations are already available. When we get there, we'll finally be arriving in the year 2012 - which is not bad, because we gain a lot of good, essential stuff, but being 5 years behind the bleeding edge on release is something I cannot wrap my head around. What ultimately boggles my mind is that WebGL implementations on top of desktop OpenGL exist - in Chrome, for instance. I have no experience in implementing browsers and sandboxing, but I cannot understand why it is no problem to basically expose a subset of desktop OpenGL, but it is aproblem to expose the whole thing. I might be wrong on this, but I suppose driver interaction for the subset is no different from driver interaction for the whole API and frankly, I cannot imagine a technical barrier for core OpenGL 4.5 support inside a browser.

On consumer platforms, we now have basically the following ways of doing things: in core OpenGL, in Vulkan, in OpenGL ES and in WebGL - and this doesn't even include all the platform specific options. All maintain their respective specifications while from a graphics programmers POV, all are (or at least partially are) means to the same end. To me, this is utter madness. I think a unified approach like Vulkan is the right direction and while OpenGL is fundamentally different in key regards, one OpenGL for all platforms would be a worthwhile option and nowadays, I cannot see why it wouldn't be possible.

With all the above in mind, I would now formulate the following hypotheses:

assuming hardware on all platforms converges to supporting both core OpenGL 4.5 and Vulkan (which, if I'm not mistaken, could already the case for recent mobile GPUs), one of the main reasons for a subset of functionality is gone
assuming that security concerns do not prohibit exposing core OpenGL 4.5 inside a browser, there is no reason to not doing it - except maybe W3C and browser vendor politics bullshit
exposing both a subset of OpenGL in the form of WebGL and a fully fledged core OpenGL 4.5 implementation inside a browser is technically not a problem and would still allow for execution on less capble hardware when needed
leveraging direct compilation to targets like WebAssembly with the complete OpenGL API exposed by the target browser would tremendously simplify the implementation of multi-platform OpenGL renderers and provide consistent UX

Still, these are just my more or less (maybe mostly less) informed thoughts and guesses, so the following questions remain:

What am I missing? What do fail to realize?
Is this even worth thinking about?
Do you see any future in which we have one OpenGL to rule them all?
Are there alternatives?

02-02-2017, 05:56 AM
I personally would say just one word, that you can start some researches with: vulkan (https://en.wikipedia.org/wiki/Vulkan_%28API%29), even if it is still at an early stage.

Hope that these few words could help you a bit...

02-02-2017, 07:47 AM
Thanks for the reply, but I specifically mention the Web as a platform, i.e. browsers would have to expose the Vulkan API and provide a Vulkan implementation. I don't see that happening any time soon so "all" that's left is OpenGL.

BTW, Vulkan is not in an early stage at all - the spec has been ratified for quite some time but you can argue that drivers haven't matured yet.