Xcb mode for linux Xorg port?

Hi,

Currently, it seems that Xlib is kind of deprecated in favor of XCB (which is automatically generated from the Xorg XML protocol file).
I’m doing some work involving low level X programming, and I was wondering if you intended to switch to the new format anytime like you did for core{graphic,audio} on Mac ?

The main advantages of XCB is lower latency (request & answer can be queued, and become asynchronous), good multithreading support (no more global XLockDisplay), smaller size & memory footprint, multi-touch support (no more work is done in XLib).
The main cons: Having to rewrite the calls from Xlib to Xcb.

I’d like to, though I’ve got very little experience of xcb so it’d be a bit of a learning curve. What’s the general availability of xcb these days? Is it there by default in most distros?

I can’t say for the pletora of linux distribution, but since Xorg 1.6 and later, it’s the library used to communicate with X server (in fact the entire Xlib is rewritten on top of xcb on Debian, Ubuntu, and Gentoo).
All new features will be in xcb only (multi-touch, advanced compositing, double buffering, protocol compression), and it seems most highlevel libraries are switching to xcb too (clutter, compiz for one).

The issue with X in general is the poor documentation for the API (Xlib is better than xcb because it’s older, you can find more sources).

Sounds interesting, I didn’t realise it was actually running below xlib these days. Thanks for the heads-up!

I realize this is a very old topic, but this is what came up when searching for “JUCE” and “xcb”.

Given that - as mentioned before - Xlib is now basically a wrapper around xcb, a switchover could be done quite gradually. It’s easily possible to retrieve the underlying xcb_connection_t from a Display (using XGetXCBConnection. That means we can take a small piece of existing code, where we work with Xlib, retrrieve the xcb_connection_t, do our work with pure xcb and leaving the rest of the code untouched.

Would PRs to this effect have any chance of getting merged?

I think that the JUCE team’s time would be better spent adding Wayland support instead.

However, if you can provide a PR that has a relatively high impact on performance without too much of a testing burden then we can certainly consider it.

1 Like