[Xcb] Synchronization problem.

[Ian Osgood]

On Aug 26, 2008, at 9:39 AM, Julien Danjou wrote:

> At 1218051476 time_t, Barton C Massey wrote:
>>> I need to sync() for an unknown reason. If I don't, some of my  
>>> requests
>>> are not (pick one or several): sent to the X server, treated by  
>>> the X
>>> server, visible on screen.
>>
>> This sounds like a bug to me.  I assume you've reported it.
>> Any test case that might let us reproduce it would be really
>> helpful.
>
> I don't have a test case yet, but sniffing with wireshark gave me  
> weird
> stuff, and I'd like an opinion.
> This is reproducible in current awesome version FWIW.
>
> I send a bunch of command via a socket to my application (awesome). It
> generates a bunch of X requests, mainly drawing and finally generating
> a CopyArea request to copy what get rendered to a pixmap.
>
> My problem is that this events are _not_ sent.
>
> Not sent, UNTIL a new event come in, and in this case the bunch of
> requests are sent out.
>
> In this example, the new event is a Leave/Enter notify since I move my
> mouse from the root window my application window after sending a bunch
> of command to my application via its socket.
>
> In wireshark I get this:
> Time            Info
> 0.0000000       Event: LeaveNotify, EnterNotify
> 0.0000006       Requests:
>                   6x Unknown OpCode 150
>                      FreePixmap
>                      FreeGC
>                   5x Uknown opcode 150
>                      CopyArea
>                   2x ConfigureWindow
>                   16x GrabButton
>                      GetInputFocus
> 0.000087       Event: …
>
> And the code of my enter notify callback function is:
> return 0;
>
> So it does not generate any more request.
>
> I don't know if it's a bug in libxcb, I'd rather think it's a misuse
> somewhere. Anyone has a pointer or something I could call to get the
> request queue size, informations, anything?
>
> Calling xcb_aux_sync() after polling events and sending requests  
> resolve
> the problem but this is not a good solution IMHO.
>
> Cheers,
> -- 
> Julien Danjou
> // ᐰ <julien at danjou.info>   http://julien.danjou.info
> // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD

When things like this don't work, try xcb_flush() after sending a  
batch of requests and before polling for events. It introduces less  
latency than the full request/reply round-trip of xcb_aux_sync().

XCB programmers run into this problem because, unlike Xlib, the XCB  
event and reply functions don't internally flush before listening for  
events.

Flush, Don't Sync: this should be (or already is) in a FAQ on the XCB  
wiki web site.

Ian