[Xcb] xlib / xcb deadlock/block

Peter Harris pharris at opentext.com
Tue Oct 19 09:34:32 PDT 2010


On 2010-10-19 12:11, Francesco Abbate wrote:
> thank you very much for the explications. I'm a little bit perplexed
> about the extrapolation you are doing from a small utils like xwininfo
> and I'm wondering about the benefit for real-world, full-fledged,
> applications.
> 
> I my application the main loop is:
> XCreateImage()
> XPutImage()
> XDestroyImage()
> XSync()
> 
> I create the image at each time because the dimensions changes but the
> allocated buffer is always the same.

The allocated buffer is always the same? Is it possible to do an
XCreatePixmap/XPutImage of the whole thing at startup and turn your main
loop into

XCopyArea()
XFlush()

(since XSync is usually overkill)?

> Do you think that in this case I can have a significant benefit with xcb ?

Probably not much.

> What should be, roughly, the xcb calls that I should use ?

XCreateImage is one of those things that Xlib provides and (core) xcb
does not. It would turn into (roughly) malloc and a few memcpys to get
the bits where you want them, or xcb_image_create from xcb/util/image.

XPutImage becomes xcb_putimage.

XDestroyImage becomes free() or xcb_image_destroy() if you're using the
xcb/util/image helper library.

XSync() becomes
xcb_get_input_focus/xcb_flush/xcb_get_input_focus_reply/free (or
xcb/util/aux xcb_aux_sync if you really want to hide what's going on).

The advantage here is that you can keep doing real work between when you
flush the GetInputFocus (Sync) request, and when you wait for the reply.
If your app doesn't have any work to do, then there probably is no
efficiency advantage to porting to XCB.

Peter Harris
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866


More information about the Xcb mailing list