> it seems quite viable to implement 2D rendering directly on GPU, with very promising quality and performance.

I guess all agree that GPU rendering is the future. Yet, I'm still in favor for libraries that abstracts the actual renderer so it could fallback if needed. Especially when future and past conflicts.

I come from audio development where people use plug-ins (dynamic libs) that loads on a host that provides native OS window you compose. Cross-platform is pretty vital so there are frameworks to target macOS, Windows, iOS (and sometimes Android & Linux).

Here is a real life scenario that many audio developers are currently at:

- you had a product with UI that needed to show 'real-time' visualization of signal - Analyzer (let's say FFT).

- eventually you went the OpenGL way (because it was the right way in 2010...) you've written shaders.

- it worked great on macOS and ok on most Windows machines (some old machines had limited or broken OpenGL within their drivers).

- Apple deprecates OpenGL in favor of Metal...

So now what was "modern" 9 years ago requires compete re-write. if there was an abstraction layer it might be minor changes and switching to new Metal renderer instead of the OpenGL one.

In comparison, The native/cpu C++ code for the same product proven to be much more future proof and only required simple maintenance.

It is indeed important work. but I guess targeting Vulkan is better especially when there are libs like MoltenVK.

I guess the question is how much portability is important factor vs optimal performance.

It exposes a common API to 3d GPU resources and implements it in terms of native backends.