Re: More on the future of cairo's X11 backends

On Wed, Jan 25, 2017 at 12:02:47PM +0100, Uli Schlachter wrote:
> Hi,
> 
> a while ago [1] I proposed merging the implementations of cairo-xcb and
> cairo-xlib into one. Back then there were concerns about a performance
> loss [2] and I have to admit this demotivated me a bit. I don't want to
> invest lots of work just to figure out that in the end the result is too
> slow.

Sympathes, performance worries have held me back on things too.  :-/

But maintainability should also be a factor we need to consider for the
long term health of the project.
 
> Anyway, let me take a step back: There are Xlib and XCB for talking to
> an X11 server. Both are being used and for both cairo offers an API.
> There are several ways how to implement something like this:
> 
> A) Have two completely separate backends with their own code paths.
> B) Implement one ontop of the other.
> C) Have common code and some thin wrapper around Xlib/XCB to make this work.
> D) I don't know. Did I miss a further possibility?

I suppose a degenerate possibility would be to deprecate the Xlib
backend with XCB the recommended default.  Then in a later release drop
Xlib entirely.  But that would break far too much code...

> Currently cairo has (A), which is bad for maintainability. The XCB
> backend started as a copy of the Xlib backend and since then the two
> diverged quite a bit. So, some things work in one, but not the other,
> some bugs are only present in one of the two etcetera.
> 
> In 2013 I proposed (B): Use XGetXCBConnection() to get an
> xcb_connection_t out of a Display. However, this means that control of
> the X11 socket is handed back and forth between XCB and Xlib quite a
> lot(?) and thus can lead to poorer performance.
>
> Since I see no other possibilities, this means that (C) is left. What I
> propose is to have thin wrappers around the X11 protocol and to add
> function pointers to the cairo device struct for calling these. As an
> example, XCopyArea(device->display, ....) would be replaced with
> device->functions->copy_area(device, ....).
> 
> For data types (Drawable vs xcb_drawable_t etc) it does not really
> matter in most cases which one is used, because both are just typedefs
> for some integer type. I would plan to use the Xlib typedef.

This seems like a sensible strategy to me.

> Something like the following:
> 
> - Introduce these function pointers in cairo-xlib and make use of them
> - Add an xcb-xlib-backend that implements the xcb API ontop of these
> function pointers
> - Eventually remove the current cairo-xcb and cairo-xlib-xcb code and
> only leave the above.
> 
> Of course this is all still a bit rough around the edges, but what do
> you think?

So do I understand this would (temporarily) add a third backend, that
implements this strategy, with the mid-range goal of eliminating two xcb
backends?  Long term does this leave us with a single X backend we have
to maintain?

Props for looking at this, simplifying these codebases would eliminate
confusing options for folks.

Bryce

> Cheers,
> Uli
> 
> [1]:
> https://lists.cairographics.org/archives/cairo/2013-September/024679.html
> [2]
> https://lists.cairographics.org/archives/cairo/2013-September/024680.html
> -- 
> Q: Because it reverses the logical flow of conversation.
> A: Why is putting a reply at the top of the message frowned upon?
> -- 
> cairo mailing list
> [email protected]
> https://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo