[cairo] The future of cairo's X11 backends

Chris Wilson chris at chris-wilson.co.uk
Sun Sep 29 05:02:06 PDT 2013

On Sun, Sep 29, 2013 at 12:11:22PM +0200, Uli Schlachter wrote:
[good summation of history]

> How can we get there?
> Since cairo-xlib is what everyone uses, I would like to keep that code.
> Hopefully, no new bugs are introduced and nobody outside of cairo notices that
> anything changed. Also, it seems to me that Chris experimented with cairo-xcb
> and those experiments lead to the compositor API which cairo-xlib now uses and
> thus cairo-xlib is technically superior.
> (The only things that I know that cairo-xcb does that aren't in cairo-xlib are
> _cairo_surface_attach_snapshot() (which causes lots of problems) and different
> approach to shared memory synchronization. None of that should be missed.)

cairo-xcb also has the ability to reduce multiple solid clears which is
a frequent enough operation that I keep meaning to do for cairo-xlib.

> My plan would be to make cairo-xlib use xcb and XGetXCBConnection() for
> everything, dump cairo-xcb and re-implement the cairo-xcb API on top of the code
> that is left. This can easily be done incrementally. Basically it is "dump
> cairo-xcb and turn cairo-xlib into a new cairo-xcb". I guess this means that the
> now-common source files and functions need to be renamed to cairo-x11-*.c and
> cairo_x11_*. :-)

That seems reasonable, but realistically what advantages does doing the
x11-to-xcb conversion in cairo-xlib give that doing it in libX11 itself
misses? I suppose marrying the cairo-device and the Display lock would
be improved. We would have to reinvent the XCloseDisplay hooks.

Chris Wilson, Intel Open Source Technology Centre

More information about the cairo mailing list