[Xcb] problem when getting replies

[Vincent Torri]

On Sun, 12 Nov 2006, Jamey Sharp wrote:

> Ah. XCB can't issue the QueryVersion request for an extension unless the
> extension is present and the QueryExtension response has already come
> back. When you call this function the prefetch_extension_data that you
> did earlier is automatically forced, and if that says the extension
> doesn't exist then the connection is shut down.

haa, that was the problem :) Thank you

> To avoid having the connection shut down when the extension doesn't
> exist, you need to call xcb_get_extension_data. (If you might send
> requests bigger than 256kB, you should turn on BIG-REQUESTS early, too.)
> In pseudo-code, your initialization should look like this:
>
> // First round trip:
> 	for each atom:
> 		xcb_intern_atom
> 	for each extension + xcb_big_requests_id:
> 		xcb_prefetch_extension_data
> 	// insert more requests with no dependencies here
> 	for each atom:
> 		xcb_intern_atom_reply
> 	for each extension:
> 		extension = xcb_get_extension_data
> // Second round trip:
> 		if(extension && extension->present)
> 			query_version
> 	// insert requests that needed atoms here
> 	xcb_get_maximum_request_length // enable BIG-REQUESTS
> 	for each extension:
> 		query_version_reply

Nice :) Ok, it works, now. Though I have a question. How do I use 
xcb_get_maximum_request_length ? I just store its value somewhere and I 
don't use it ? Or should I use it somewhere ?

> That's two round trips, and you can't do any better in the X protocol, I
> believe. (Bart and I were discussing yesterday that the TCP three-way
> handshake and the connection setup request and reply are two more
> round trips, so to be really pedantic you could say you need four round
> trips to get going.) You probably need one more after the QueryVersion
> replies come back to actually use the extensions you want, but I think
> in 3 (or 5) round trips you're all set and ready to do real work.

ok. That's already better than Xlib. Here is a small bench for the 
initialization of ecore_x(cb):

ecore_x time...: 0.009973
ecore_xcb time.: 0.002292

That is, almost 5 times faster. I don't think I can do much more. I don't 
know if that is important for the numbers, but I run a non optimized XCB 
(compiled with -g).

> BTW, you can check whether your server supports DAMAGE with either
> xdpyinfo or xcbdpyinfo: both provide a list of supported extensions.

Indeed, I do not support the damage extension (I run xorg 6.7...)

> p.s. We should probably add a prefetch_maximum_request_length function
> for initialization purposes. Currently xcb_get_maximum_request_length
> always takes a round-trip the first time it's called. In the above code
> I was careful to place it where we were about to block for round trip
> latency anyway, but this ordering has potentially reduced parallelism.

That would be nice if you can write such function :)

Many thanks, Jamey :) Now, ecore_xcb should work, except some minor fixes 
to do :) The biggest fix would be to improve my ugly api :)

Vincent