[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cairo
Subject:    Re: [cairo] Release management for Cairo
From:       Bill Spitzak <spitzak () gmail ! com>
Date:       2021-04-26 19:17:48
Message-ID: CAL-8oAgtW2ZVcbzjwp-K_fuoHAspFh0r4mAZ3rMUZOVhiLm-QA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

On Mon, Apr 26, 2021 at 9:03 AM Uli Schlachter <psychon@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@cairographics.org
> https://lists.cairographics.org/mailman/listinfo/cairo
>

[Attachment #5 (text/html)]

<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><br></div><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><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 9:03 AM \
Uli Schlachter &lt;<a href="mailto:psychon@znc.in">psychon@znc.in</a>&gt; \
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>
&gt;   - Xlib<br>
&gt;   - 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&#39;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>



-- 
cairo mailing list
cairo@cairographics.org
https://lists.cairographics.org/mailman/listinfo/cairo


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic