Re: XCB (Was Re: Window managers ( was Re: newbie question ))

[hns]

On 23 Apr., 17:18, David Chisnall <thera...@sucs.org> wrote:
> Hi Fred,
>
> On 23 Apr 2009, at 16:12, Fred Kiefer wrote:
>
> > could you please detail a bit on the benefits of an XCB backend  
> > compared to an Xlib one?
> > As you already pointed out newer versions of Xlib are internally  
> > able to use XCB, so what can we gain by using it directly?
>
> The big advantages (apart from linking against a much smaller library)  
> are that XCB has a design which is trivial to integrate with a GNUstep  
> runloop (i.e. it provides a file descriptor that you can add to the  
> run loop and receive notifications when there are pending events,  
> which is what I am doing) and that it is much better at latency  

Hm. That is also available in xlib (and I use that in mySTEP):

[[NSFileHandle alloc] initWIthFileDescriptor:XConnectionNumber
(_display)]

> hiding.  A lot of XLib calls attempt to provide a synchronous API on  
> top of an asynchronous protocol, so the client (GNUstep app) is  
> spending time waiting for the round trip to the server.  On a local  
> machine this just adds a bit of overhead, but on a remote system even  
> on a local network it is common for the GNUstep app to be spending  
> more than 50% of its time in a blocking state waiting for data from  
> the X server which is not really required immediately.  XCB is a pure  
> asynchronous design, using futures, and lets you fire off messages to  
> the X server and not block for receiving the replies until you  
> actually need them.

I have looked into this recently for mySTEP and seen no benefit (yet),
although it shares the same slowness with GNUstep if run over a
network (XGetImage & XPutImage appear to be quite slow).

AFAIK, pure drawing primitives are even buffered in the client and
sent in a single large request without waiting for a response. IMHO,
xlib blocks only if it needs to. I.e. if you ask for some value from
the server (window attributes, properties, etc.). So, you have to
synchronize anyway. I.e. an orderFront: should wait until the window
appears or there can arise race conditions with the isVisible status
flag. Well, doing that by running the NSRunLoop could allow to run
other application tasks like NSTimers in between - but you have more
overhead by the NSRunloop - and it may result in strange side effects
in the NSTimer action method if that asks for the NSWindow status.

So we should identify what the "data from the X server which is not
really required immediately" really is.

IMHO the real speed-up is by avoiding XGetImage at all (unless you
want to program a screen dump) and use XPutImage only once per image.
This requires heavy use of XRender.

Nikolaus