On 27 Nov 2019, at 18:29, Ivan Vučica <[email protected]> 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
