Whats holding ~100% D GUI back?

[Ola Fosheim Grøstad]

On Friday, 29 November 2019 at 09:00:20 UTC, Gregor Mückl wrote:
> These 2d rendering engine in Qt, cairo, Skia... contain proper 
> implememtations for primitives like arcs, polylines with 
> various choices for joints and end caps, filled polygons with 
> correct self-intersection handling, gradients, fill patterns, 
> ... All of these things can be done on GPUs (most of it has), 
> but I highly  doubt that this would be that much faster. You 
> need lots of different shaders for these primitives and 
> switching state while rendering is expensive.

Well, the whole topic is quite complex. One important aspect of 
this is that a UI should leave as much resources to the main 
program as possible (memory, computational power and reduce power 
consumption as much as possible). Another aspect is that users 
have veeery different hardware. So, what works well on the GPU on 
one machine and with one application, might not work well with 
another. Games can make other assumptions than UI frameworks...

But I think the most important aspect is that hardware change 
over time, so what is available in the standard API may not 
reflect what you can do with extensions or a proprietary API. As 
far as I can tell, there is a push for more RISC like setups 
(more simple cores) with more flexibility, but I don't know how 
far that will go. Maybe the whole coprocessor market will split 
into multiple incompatible lanes with a software API layer on top 
(like we see with OpenGL over Metal on OS-X, just with more 
distance between what the API delivers and what the hardware 
supports). AI and raytracing could lead to a departure in 
coprocessor tech...

Having a software renderer (or CPU/GPU hybrid) clearly is the 
most portable approach, going GPU only seems to be a risky 
venture that would require lots of developers to target new 
architectures as they appear.