Re: The future of cairo's X11 backends

Uli Schlachter <[email protected]>
Newsgroups gmane.comp.lib.cairo
Message-ID <[email protected]>
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.
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.