Xlib vs. XCB: What should I do, yet?

dav7 · 2008-11-29 00:56:15

So I'm working on a little project whose goal is to be as small as possible - small enough to fit on a floppy disk. To this effect, I started using Xlib for all basic drawing and developing directly on top of that, instead of using a higher level toolkit.

All went well for a little while, then I explained my situation to #xorg-devel to get help with a problem and they recommended I use XCB instead of Xlib for my work.

For those who don't know, XCB aims to be a complete Xlib replacement as a way to talk X protocol. Compared to libX11 (1.1MB), libxcb is a lot smaller (134K), a lot more compact, etc. Yes, it uses a completely different API, but includes a unique way to allow you to mix Xlib and XCB calls freely by including a certain library, to assist in smooth porting.

For those of you who do know, you don't need to tell me why XCB is better. I know about the fact that it's simply faster. I heard one of the developers tell me the results of a quick benchmark: a given library he'd ported from Xlib to XCB cut startup time over ssh -X from 6 seconds to 1 second. You don't need to tell me that binaries linked with XCB are smaller than equivalents linked with Xlib. I know all this stuff.

I'm just confronted with the issues below.

- XCB is less documented than Xlib.
- From the perspective of an Xlib developer, XCB isn't all that intuitive to figure out. I blame Xlib for this, but the lack of documentation doesn't make things very easy.
- XCB doesn't appear to know about VNC displays, at least not when reading the keyboard (which a friend confirmed). I also had an odd experience with keyboard reading on my normal X server: a test app would refuse to quit when I hit ESC, then when I told #xcb about this it suddenly worked.
- XCB doesn't appear to include functions like XTextExtents, and when I asked where I'd find such a function I was told that the devs often just look at Xlib to figure out how to duplicate behavior in XCB. Er, I want to use the API, not write it
- XCB has no equivalent to Xlib's XStringToKeysym, which I have no idea how to reimplement using XCB, so at the moment I'd have to include BOTH libraries in my project, sending disk usage right over the 1.44MB barrier.

The fifth issue really is the breaker for me.

So I propose a possible solution, and request your help in figuring out what to do from here.

My solution is to write a parser in for example PHP (mostly because it's the only high-level language I know, and I don't feel like learning another at the moment, C is plenty) which scans a tree of user source code and lists what datatypes are used and function calls made. It then goes through the sourcecode of a bunch of libraries and drills down to what calls are made where, figures out what function calls and/or datatypes are simply not used in the library(s), and comments them out.

This is a really bad example below, but illustrates my point. If you had libfoo providing something like this

struct {
int a;
int b;
} datatype1;

struct {
char *hi = "hi";
int b;
} datatype2;

void abc(struct datatype1 foo) {
  
  struct datatype2 bar;
  foo.a = 1;
  def(bar);
  
}

void def(struct datatype2 bar) {
  
  puts(bar.hi);
  
}

And my code called it like

include "libfoo.h"

int main() {

  struct datatype1 ohai;
  
  abc(ohai);
  
  return 0;
  
}

All the code in libfoo would be included. But if my code called it like

include "libfoo.h"

int main() {

  struct datatype2 ohai;
  
  def(ohai);
  
  return 0;
  
}

libfoo might look like this before compilation

/*struct {
int a;
int b;
} datatype1;*/

struct {
char *hi = "hi";
int b;
} datatype2;

/*void abc(struct datatype1 foo) {
  
  foo.a = 1;
  def(bar);
  
}*/

void def(struct datatype2 bar) {
  
  puts(bar.hi);
  
}

because nothing referenced abc or datatype1.

So what do you think? Should I either...

> Struggle along with XCB, accept the XStringToKeysym issue, work on applications and create my first build of this project when XCB has its own equivalent

-or-

> Use Xlib, write the parser I speak of above and run Xlib through it when I do full rebuilds, and wait for XCB to fix its issues with VNC displays and apparent lack of API function calls before I port everything over

...?

I plan to move heavily used functionality into a library of my own, so it wouldn't be too hard to port if I choose to wait.

-dav7

Last edited by dav7 (2008-11-29 07:45:45)

slougi · 2008-11-30 20:25:26

xcb in general is very close to the X protocol. Usually you can figure out how a lot of the functions work by looking at the protocol documentation (for example at http://ftp.x.org/pub/X11R7.4/src/doc/xo … .4.tar.bz2, look in hardcopy/Xprotocol, it contains gzipped PS files).

note: I have not done a lot of xcb programming, I haven't needed to. I am more familiar with xlib.

Last edited by slougi (2008-11-30 20:25:49)

catwell · 2008-12-01 01:40:04

It should have be taken care of by the X team, as stated in this thread. It looks like they have forgotten about it...

dav7 · 2008-12-01 04:13:46

slougi: I see. I'm more familiar with Xlib, it's just bigger

catwell: Heh, I read that thread a little while ago.

-dav7

Arch Linux

#1 2008-11-29 00:56:15

Xlib vs. XCB: What should I do, yet?

#2 2008-11-30 20:25:26

Re: Xlib vs. XCB: What should I do, yet?

#3 2008-12-01 01:40:04

Re: Xlib vs. XCB: What should I do, yet?

#4 2008-12-01 04:13:46

Re: Xlib vs. XCB: What should I do, yet?

Board footer