回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)

[Max Chan]

We can treat the internals of a window as a composite of views, then apply the 
same philosophy.
 
-----邮件原件-----
发件人: David Chisnall <theraven@theravensnest.org> 
发送时间: 2019年11月28日 2:59
收件人: Ivan Vučica <ivan@vucica.net>
抄送: Max Chan <xcvista@me.com>; Discuss-gnustep Discuss <discuss-gnustep@gnu.org>
主题: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which 
ObjC2.0 features are missing in the latest GCC?)

On 27 Nov 2019, at 18:29, Ivan Vučica <ivan@vucica.net> wrote:
> 
> I will intentionally not discuss this further, and I have 
> intentionally not dug very deep. I don't want to be overly exposed to 
> ideas beyond the APIs.

Apple wrote quite a lot publicly about how their fast rendering server (Quartz 
Extreme!!11eleventyone) worked, and it’s very similar to how most modern GUIs 
work.  XDAMAGE, XRENDER and XCOMPOSITE expose all of the things required to do 
the same on X11.  Their main innovation was that, for each font, they 
pre-rendered all of the glyphs and did server-side compositing.  This 
dramatically sped up text rendering: the previous bottleneck was rendering all 
of the bezier paths (Microsoft Research published a faster way for GPUs almost 
20 years ago, which involved turning each bezier into two triangles [one vertex 
and both control points] and then having a pixel shader that coloured in the 
triangles so that they only rendered the bezier path parts, but Apple’s 
approach is very fast anyway).

On a modern GPU, modifying a texture is very expensive, but compositing is 
basically free.  On a CPU, modifying a texture is cheap and compositing is 
relatively expensive.  The interface that you want from the GUI stack to the 
display server (X11 or whatever) should favour storing rendered things on the 
server and should provide the regions that need redrawing.  If you’re using a 
GPU, rendered things can be stored as textures and composited for free.  If you 
need to redraw something, you can render to texture and then cache the result 
and composite that.

This design also benefits CPUs and remote display over a network: on a CPU, you 
can cache pre-composited regions and only re-composite the necessary bits.  
Even that’s pretty cheap on a modern CPU (compositing is basically a zip 
operation on a pair of byte arrays): old 2D accelerators had fixed-function 
hardware for it but they don’t really exist anymore because 10-year-old CPUs 
are more than fast enough.

I haven’t looked at the Cairo back end, but from what I’ve seen of its 
behaviour, my guess as to some of the performance issues:

 - It is redrawing a lot more than it needs to.  There may still be the double 
buffering inherited from the ART back end, but I’ve seen the entire window 
flicker when only a small portion should be redrawn.

- There’s no CALayer support, so redrawing a view always involves redrawing all 
subviews, even ones that haven’t changed.  Pretty much all other modern 
toolkits have sone CALayer equivalent and so can cache expensive to render and 
just recomposite them.  This is particularly noticeable over remote X11, where 
those images are cached on the display server and only the redrawn bits need to 
be transferred over the network.

David