User: Password:
|
|
Subscribe / Log in / New account

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 11:27 UTC (Wed) by farnz (subscriber, #17727)
In reply to: The Wayland Situation: Facts About X vs. Wayland (Phoronix) by k8to
Parent article: The Wayland Situation: Facts About X vs. Wayland (Phoronix)

The difficulty with XCB (as compared with XLib) is that it exposes the request/response nature of X11 directly to the application.

For example, in XLib, if I want to find my parent window, I call XQueryTree(), which blocks me until the X server replies with all requested information.

To do the same with XCB, I need to use two of the window manipulation functions; I first call xcb_query_tree(), which returns a magic cookie. I then have to call xcb_query_tree_reply() to get at the result of my query tree operation.

This does give XCB two potential performance advantages when running over the network; the first is that I can often change my logic to send lots of requests, flush, then wait for the replies, which permits me to send larger network packets (as it sends all the requests in a minimum number of packets, rather than sending one packet for each request because XLib has blocked). The second is that I can hide latency; if I know that I'll need a reply in order to start processing the next iteration of a loop, I can send the request, do my processing for this iteration, then wait for the reply. For example, if I'm walking up the window tree and doing something at each level, I can code my loop as (pseudo-code):

analyse_parent_windows( connection, window, callback )
{
    parent_cookie = xcb_query_tree( connection, window );
    while( window != root_window )
    {
        reply = xcb_query_tree_reply( connection, parent_cookie, error );
        handle error;
        parent_cookie = xcb_query_tree( connection, reply.parent );
        callback( connection, reply.parent );
    }
}
This submits the request for the next parent while I'm still processing this window, and hopefully reduces the time I spend stalled waiting for X to reply. The equivalent done with XLib would have to wait after each query_tree operation for the X server to reply, resulting in lost time.


(Log in to post comments)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 21:02 UTC (Wed) by k8to (subscriber, #15413) [Link]

So just the usual extra work associated with nonblocking I/O, basically?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 16:21 UTC (Fri) by farnz (subscriber, #17727) [Link]

Pretty much that, plus some pain where XLib did multiple X roundtrips in one call (e.g. XQueryTree), and you now have to manage multiple request/reply pairs. There's also a small and shrinking area of pain where an extension is XLib-only, and you have to use XCB/XLib interop.

Additionally, the problems XCB fixes aren't visible if you do what most people do and use a local X server - they're only a pain if you want to use X over the network. So, for most developers, why port to XCB when you get easier, cleaner code with XLib?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 16:52 UTC (Fri) by dark (guest, #8483) [Link]

We might need a library that makes using XCB easier :) And I don't mean one that tries to be a layer on top (that would be libX11 all over again), but a library that provides tools for managing multiple related xcb calls, helpers for useful patterns like prefetching, and tons of convenience functions for common operations.

Unfortunately I probably wouldn't work on such a library because I'm not involved with any X11 based code anymore.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 15, 2013 1:32 UTC (Sat) by hummassa (subscriber, #307) [Link]

> We might need a library that makes using XCB easier

it's called Qt. :-D


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds