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

List:       cairo
Subject:    Re: [cairo] Release management for Cairo
From:       Emmanuele Bassi <ebassi () gmail ! com>
Date:       2021-04-27 12:01:59
Message-ID: CALnHYQGD7=CWzb_2xoSugWKcrLHsK7NikshDkv69=QSC8VVFKg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Mon, 26 Apr 2021 at 17:03, 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.
>

It would be interesting to have a cairo-xlib-over-xcb surface to test out,
but I am loath to sink more time on anything related to X11.

For instance: GTK still uses Xlib, and it won't ever switch to XCB;
partially because API, and partially because X11 is pretty much legacy
tech, at this point.

Having said that: if it's feasible to build a cairo-xlib version that uses
XCB on the backend—i.e. expose the cairo-xlib API but internally use
XCB—and it's possible to verify that it does not introduce regressions,
then I don't see why anybody should block that effort. Bugs are bugs,
whether they are known or not.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr">On Mon, 26 Apr 2021 at 17:03, Uli Schlachter &lt;<a \
href="mailto:psychon@znc.in">psychon@znc.in</a>&gt; wrote:<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">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></blockquote><div><br></div><div>It would be \
interesting to have a cairo-xlib-over-xcb surface to test out, but I am loath to sink \
more time on anything related to X11.</div></div><div \
class="gmail_quote"><br></div><div class="gmail_quote">For instance: GTK still uses \
Xlib, and it won&#39;t ever switch to XCB; partially because API, and partially \
because X11 is pretty much legacy tech, at this point.<br></div><div \
class="gmail_quote"><br></div><div class="gmail_quote">Having said that: if it&#39;s \
feasible to build a cairo-xlib version that uses XCB on the backend—i.e. expose the \
cairo-xlib API but internally use XCB—and it&#39;s possible to verify that it does \
not introduce regressions, then I don&#39;t see why anybody should block that effort. \
Bugs are bugs, whether they are known or \
not.<br></div><div><br></div><div>Ciao,</div><div>  Emmanuele.<br></div><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>



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