Whats holding ~100% D GUI back?

[Basile B.]

On Friday, 29 November 2019 at 09:00:20 UTC, Gregor Mückl wrote:
> On Friday, 29 November 2019 at 08:45:30 UTC, Gregor Mückl wrote:
>> On Friday, 29 November 2019 at 06:02:40 UTC, Ola Fosheim 
>> Grostad wrote:
>>> So you need a CPU software renderer to fall back on, GPU 
>>> rendering is more of an optimization in addition to CPU 
>>> rendering. But more and more is moving to the GPU.
>>>
>>> Look at the roadmap for Skia to get an idea.
>>
>> Yes, proper drawing of common 2d graphics primitives is hard.
>
> Accidentially hit send too early. Sorry.
>
> I am not aware of a full GPU implementation of a TTF or OTF 
> font renderer. Glyphs are defined as 2nd or 3rd order splines, 
> but these are warped according to pretty complex rules. All of 
> that is often done with subpixel precision to get proper 
> antialiasing.
>
> These 2d rendering engine in Qt, cairo, Skia... contain proper

cairo is not comparable to Skia or Qt, it's more an intermediate 
level API, which can use itself different backends. But it's 
clearly lower level than Skia for the few I know of it.

> 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.

Back in the early 2010's I used something comparable to QtQuick 
and it had different backends. On Windows we could choose between 
GDI+ and D2D+DirectWrite. The later, while using the GPU was 
awefuly laggy compared to the good old GDI+.

Back to the original topic. What people don't realize is that a 
100% D GUI would be a more complex project than the D compiler 
itself. Just the text features is a huge thing in itself: 
unicode, BDI.