[Xcb] [Bug 4232] xlsclients much too slow over network

Jim Gettys jg at freedesktop.org
Thu Sep 3 07:11:26 PDT 2009

Peter Harris wrote:
> On Wed, Sep 2, 2009 at 6:55 PM, Alan Coopersmith wrote:
>> Peter Harris wrote:
>>>  - Most of those round-trips were spent in XmuClientWindow, and most of
>>> the rewrite was open-coding XmuClientWindow so it could be run in parallel.
>> Since there were enough callers in the old world to make an
>> XmuClientWindow useful, does that suggest this should become
>> a shared utility function in something like xcb-util?
> Interesting question.
> XmuClientWindow itself could be rewritten using xlib-xcb for a modest
> speed gain[1] in all those old apps without having to touch any of
> them. But it wouldn't be anywhere near the speedup seen in xlsclients,
> since it wouldn't run all the toplevel windows in parallel.
> What is the typical usage of XmuClientWindow? An xcb-util function
> that returns a list of all the client windows on a screen could be
> useful, if that was a common pattern.
> Peter Harris
> [1] O(tree_depth) vs O(tree_width*tree_depth)

I think the immediate question is whether GTK or Qt use XmuClientWindow 
or similar things they've coded internally...

I'd sure like to get trace data for current desktop behavior using the X 
protocol.   Xcb has the potential to greatly improve performance; but 
where to first look for the biggest bangs for the bucks isn't clear...

I'm trying to interest people in Bell Labs to look at all the  current 
remote graphics protocols (not specifically X, but the larger set of X, 
RDP and VNC at a minimum) as remote graphics is central to a major 
project we've undertaken. I don't know if I'll succeed or not.  I'm at a 
few nibbles stage right now, but haven't landed any fish so far...
			- Jim

More information about the Xcb mailing list