[cairo] The future of cairo's X11 backends

[Uli Schlachter]

On 29.09.2013 14:02, Chris Wilson wrote:
> 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.

And it also has some assert()s to make sure that unsupported requests are not
sent to the server. I mean things like this in
_cairo_xcb_connection_render_create_picture():

    assert (connection->flags & CAIRO_XCB_HAS_RENDER);

This makes sure that cairo_xcb_device_debug_cap_xrender_version() really works
(at least the biggest part of it, it doesn't test for unsupported operators).

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

I am not sure I understand. Do you mean "xlib already talks to xcb for us, why
would we want to talk to xcb directly"?

The reason for that would be: cairo-xcb exists and (hopefully) doesn't go away.
Thus cairo has to be able to work with just an xcb_connection_t* instead of a
Display*. It does so already, but this was done via copying the backend which
seems wasteful.

(Put differently: I don't want to fix things in cairo-xcb that work fine in
cairo-xlib. :-) )

Cheers,
Uli
-- 
Bruce Schneier can read and understand Perl programs.