[Xcb] [PATCH:xwininfo] Convert from Xlib to xcb

[Peter Harris]

On Mon, Jun 14, 2010 at 11:16 AM, Alan Coopersmith wrote:
>
> Some other things I probably should have mentioned:
>
>  - If you run xwininfo with the argument "-name foo" it starts at root and
>   crawls down the tree looking at every window's name until it finds one
>   named "foo" (via Window_With_Name() in dsimple.c) - in making this code
>   asynchronous it will over-prefetch.   At each node in the tree that it
>   visits, it calls xcb_get_wm_name & xcb_query_tree up front for all the
>   children, and then goes through the results.   If it finds a match it
>   then calls xcb_discard_reply for the rest of the cookies.   This trades
>   the latency of the many waits for round trips in the Xlib version for a
>   bit of extra bandwidth and some number of requests that are likely to be
>   discarded in the end.

That's what I thought too (when I did xlsclients), but it turns out
not to be the case (on average) for bandwidth.

Upon further reflection, bandwidth costs in the Xlib case are
dominated by overhead. TCP+IP+Ethernet = 66.

So due to Xlib forcing a new network packet for each round trip, XCB
can request and receive 10 each of GetProperty and QueryTree in
slightly less bandwidth than Xlib can do 4[1]. This is a slight loss
if you hit on the first or 2nd window and discard the rest, and a huge
gain if you never hit (and never discard).

So not only does XCB win huge in latency, XCB also wins somewhat in
bandwidth even when you discard (on average) half of the replies.

Peter Harris

[1] Assuming a window name roughly 10 characters long, and 10
subwindows per window. GetProperty request = 24 bytes, reply = 32 +
pad(n) = 42 bytes. QueryTree request = 8 bytes, reply = 32 + 4n = 72
bytes.

These are conservative numbers, chosen to favour Xlib, since most
windows don't have a name set. Therefore, replies are smaller on
average and Xlib's per-reply overhead matters even more.