Is the use of OpenGL restricted to creating graphics intensive softwares?

Question

OpenGL is great in creating UI (specially in games) and it is highly portable. Is it unusual that an ordinary (not graphically intensive) application uses OpenGL for its UI? And if not, why? Is it about performance or ease of use?

For example, an Apple developer can use ready to use buttons and sliders, etc provided by Apple; he can also create the UI using OpenGL. The second method makes the code more flexible and portable. Why people don't do this?

Does using OpenGL makes sense if portability is our goal?

Answer 1

Yes, what you suggest is possible. Just have a look at Blender. Blender implements its own UI using OpenGL, for the exact portability reasons you gave.

However there's a lot more to user interfaces than just getting things drawn to the screen. Event management, input handling, interoperability with other applications. All that depends on functions that are not covered by OpenGL.

But there are cross platform application framework libraries, like Qt. And the whole drawing stuff makes only a small portion of what those frameworks do.

One problem you run into when using OpenGL for drawing the GUI though is, that there's a huge variation on the OpenGL profiles supported by the systems out there. It can vary from a mere OpenGL-1.1 software fallback on a old Windows XP machine, over OpenGL-1.4 on Windows Vista machine with only the default drivers installed by the Windows setup, up to OpenGL-4.5 on the same machine once that user installs the proper drivers. And the way you use OpenGL-4.5 is largely incompatible to OpenGL-1.4.

For a UI toolkit written with a OpenGL backend this means that you must implement at least three codepaths: A OpenGL-1.1 variant that uses the fixed function pipeline and client side vertex arrays. A OpenGL-3 compatibility profile. And a OpenGL-4 core profile.

This much more work than just using the OS specific methods, which you have to use anyway to create the window and get user input with.

Answer 2

There's a lot more to UI than graphics.

As one example fonts. Rendering Chinese, Japanese, Korean, Arabic, Thai in the right directions with the write strokes etc it a TON of work. There are whole teams dedicated to that topic at Microsoft, Google, Apple, Adobe and other companies. If you go straight to GL you're going to have to solve that problem yourself.

Another example, native controls. iOS users expect certain controls to work a certain way. Android users expect something different. For a game that's usually not a problem, games usually have a very unique UI. Apps on the other hand are generally expected to stick to the conventions of their target platform. Generally users get upset when the controls don't match their native platform. Using GL for your UI means you won't get the native controls.

Similarly text editing is a very platform specific feature. Is it drag to select, right click to select, hold to select? What keys go which way, how do they work? Is it Ctrl-V or ⌘-V. All of that is platform dependent as well. You can use the native text editing controls and have the problem solved or you can use GL and have to reproduce not only all the code to edit text but try to make it work the right way on each platform in each configuration. Does your GL text editor handle Japanese keyboards? German Keyboards? Does it handle Input Method Editors for CJK and others?

So, it's more a matter of the right tool for the right job. There are whole UI platforms written on top of GL. Before Metal OSX was probably one of them (or still is?) But if you skip that and build your UI directly on GL you'll end up having to implement all those in-between pieces.

Certainly GL might be the right way to go for certain non-game apps. Paper comes to mind as an app that could be 98% GL and therefore gain portablility. On the other hand Evernote is probably on the far other side. It needs to handle every language, different fonts, input for users with disabilities, etc. All of that is built into the OS, not GL.