[cairo] The future of cairo's X11 backends

[Siarhei Siamashka]

On Sun, 29 Sep 2013 12:11:22 +0200
Uli Schlachter <psychon at znc.in> wrote:

> Hey everyone,
> 
> since 2004 (commit 810037bc), cairo has two separate X11 backends which shared
> no backend-specific code. Time passed and the xcb backend bitrotted while the
> xlib one was developed further. In 2010 (commit 1236c410), Chris rewrote and
> improved the xcb backend a lot and IMHO since then it is pretty much usable.
> 
> However, there is no good reason for having these two separate. Since 2004, Xlib
> has XGetXCBConnection() which allows mixing Xlib and xcb operations on the same
> socket. The xcb-support in Xlib isn't optional since version 1.4.0 from 2010.
> Chris used this for cairo's "xlib-xcb backend" which implements the cairo-xlib
> API and uses xcb surfaces "behind the back" for all operations.
> 
> Obviously it would be great if cairo just had a single X11 backend which means
> less code, less maintenance and more happy people. This is where I am trying to get.
> 
> The ugly approach for this would be to have a thin abstraction layer which hides
> all the differences between Xlib and xcb.
> 
> My preferred approach instead is something like the current cairo-xlib-xcb code,
> mostly because it is simpler and the only downside that I can see is that cairo
> now depends on an xcb-enabled Xlib.
> 
> 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.)
> 
> 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_*. :-)
> 
> What do others think about this plan? Anything that I miss, any objections,
> anyone who still uses cairo with Xlib 1.0?

The plan should be fine as long as it does not introduce performance
regressions. Currently the xcb backend performs worse than xlib in
cairo-perf-trace benchmarks. Maybe that's because the xcb cairo backend
is less advanced. Or maybe the xcb itself has some deficiencies (sounds
unlikely, because right now xlib is an emulation layer on top of xcb,
but still needs to be confirmed to be sure).

It should not come as a surprise that the cairo xlib backend with
xf86-video-fbdev ddx is slower than the cairo image backend, partially
thanks to the communication overhead. And the quality of the xlib/xcb
implementation is also contributing here.

The performance of the bulk one-way fire-and-forget communication with
the X server is important if we ever want to reduce the performance gap
between the xlib/xcb and image backends in cairo. And from what I could
see, xcb has always focused primarily on optimizing the round-trip
latency, which is a bit different use case.

-- 
Best regards,
Siarhei Siamashka