[cairo] Release management for Cairo

[Emmanuele Bassi]

On Mon, 26 Apr 2021 at 20:17, Bill Spitzak <spitzak at gmail.com> wrote:

> If somebody really wants to get in there and get development started on
> this again, that would be great! Maybe Cairo can be saved. There was hope
> once upon a time that all the toolkits would use Cairo for drawing. Instead
> all the toolkits are writing their own rendering code, a redundant waste of
> resources. Imagine if all that work had gone into Cairo!
>

The problem is that the Cairo design is fundamentally at odds with the way
GPUs operate, with its constant read-back and the geometry submission.
Implementing the CSS state using GLSL shaders, for instance, is easier than
trying to implement the Cairo state.

This alone would have required a dramatic API break, which is certainly not
what consumers of Cairo would have wanted—which is why it never happened.
Plus, of course, the well-known maintenance issues.

Plus, not every toolkit would have ever switched to Cairo; GTK was probably
going to be the only one, as Qt has always had their own rendering pipeline.

The xlib backend is partially implemented by pixman and that has been a
> problem as there is even less maintenance of that. If I understand
> correctly, pixman is supposed to be in the X server, but such remote
> rendering is used very little, or none, by Cairo (the xlib backend triggers
> a switch to local rendering in many cases, and Wayland does not support
> remote rendering at all). It is obvious the X server is not passing
> everything through unchanged to pixman, making the idea that local and
> remote rendering can share code by reusing the pixman api not work in
> practice. I think it would be a good idea to dump pixman (and remote xlib
> rendering), moving the code to Cairo xlib backend and (hopefully) cleaning
> it up.
>

There's no point in moving rendering commands over to the display server:
not only it is X11-specific and X11 is essentially in maintenance mode, but
it's also fundamentally not how "modern" X11 works. Toolkits do client side
rendering for everything, and have been doing that for the past 20 years.
The only benefit of using remote XRENDER calls is that the X server can use
a GL-accelerated implementation, which is definitely better than the
pixman-based one; but, again, focusing on X11 is a losing proposition. On
Wayland, toolkits use the image surface because then they can upload it to
an EGL buffer for a GL-based compositor to present to the user.

We can keep the xlib (and xcb) surfaces, but the windowing system they
target is legacy, and I expect that API to be phased out eventually.

Ciao,
 Emmanuele.


> On Mon, Apr 26, 2021 at 9:03 AM Uli Schlachter <psychon at znc.in> wrote:
>
>> Am 25.04.21 um 19:12 schrieb Emmanuele Bassi:
>> [..]
>> >  - Xlib
>> >  - XCB
>>
>> P.S.: AFAIK cairo-xcb started as a fork of cairo-xlib that then got a
>> rewrite. Or three. It would be nice to merge them into a single
>> cairo-x11 backend.
>>
>> Once upon a time, I suggested removing cairo-xlib and relying on the
>> existing cairo-xcb-xlib mechanism to provide the cairo-xlib API. This
>> was rejected because it would introduce new bugs. The existing
>> cairo-xlib bugs are at least known.
>>
>> Providing cairo-xcb ontop of cairo-xlib is not possible, so back then I
>> started working on a little cairo-internal X11 abstraction that could
>> then be implemented for both xcb and xlib. I did this by starting from
>> the existing cairo-xlib backend so that (hopefully) no new bugs are
>> introduced. I stopped (in 2017, according to git) because I didn't
>> really see the point anymore (neither backends had any activity, so
>> trying to merge them also had little gain).
>>
>> Anyway, why I explain this:
>> If wanted / deemed useful, I can try to continue working on this.
>> --
>> “Some people are worth melting for.” - Olaf
>> --
>> cairo mailing list
>> cairo at cairographics.org
>> https://lists.cairographics.org/mailman/listinfo/cairo
>>
>

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20210427/d1b31a44/attachment.htm>