<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 26 Apr 2021 at 20:17, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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!</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Ciao,</div><div class="gmail_quote"> Emmanuele.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 9:03 AM Uli Schlachter <<a href="mailto:psychon@znc.in" target="_blank">psychon@znc.in</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 25.04.21 um 19:12 schrieb Emmanuele Bassi:<br>
[..]<br>
>  - Xlib<br>
>  - XCB<br>
<br>
P.S.: AFAIK cairo-xcb started as a fork of cairo-xlib that then got a<br>
rewrite. Or three. It would be nice to merge them into a single<br>
cairo-x11 backend.<br>
<br>
Once upon a time, I suggested removing cairo-xlib and relying on the<br>
existing cairo-xcb-xlib mechanism to provide the cairo-xlib API. This<br>
was rejected because it would introduce new bugs. The existing<br>
cairo-xlib bugs are at least known.<br>
<br>
Providing cairo-xcb ontop of cairo-xlib is not possible, so back then I<br>
started working on a little cairo-internal X11 abstraction that could<br>
then be implemented for both xcb and xlib. I did this by starting from<br>
the existing cairo-xlib backend so that (hopefully) no new bugs are<br>
introduced. I stopped (in 2017, according to git) because I didn't<br>
really see the point anymore (neither backends had any activity, so<br>
trying to merge them also had little gain).<br>
<br>
Anyway, why I explain this:<br>
If wanted / deemed useful, I can try to continue working on this.<br>
-- <br>
“Some people are worth melting for.” - Olaf<br>
-- <br>
cairo mailing list<br>
<a href="mailto:cairo@cairographics.org" target="_blank">cairo@cairographics.org</a><br>
<a href="https://lists.cairographics.org/mailman/listinfo/cairo" rel="noreferrer" target="_blank">https://lists.cairographics.org/mailman/listinfo/cairo</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><a href="https://www.bassi.io" target="_blank">https://www.bassi.io</a><br>[@] ebassi [@<a href="http://gmail.com" target="_blank">gmail.com</a>]</div></div>