Beginner Questions About XCB - xcb_alloc_color is too slow

[Carsten Haitzler]

On Sat, 20 Feb 2021 22:08:21 -0500 Sam Varshavchik <sam.varshavchik at gmail.com>
said:

> On Sat, Feb 20, 2021 at 9:37 PM Mark Solomonik
> <marik.solomonik at gmail.com> wrote:
> >
> > Hello,
> > I am trying to implement a 3D engine from scratch with XCB. To do this, I
> > have to set the color of every individual pixel before drawing it.
> >
> > I noticed that calling xcb_alloc_color and xcb_alloc_color_reply are
> > bottlenecking the program and making it slow to draw individual triangles.
> 
> I made the same mistake a while ago. AllocColor is superceded by the
> RENDER protocol extension which, if you dig into it, you can find out
> which bits in a 24 or a 32 bit pixel correspond to the

That's not true. XRender allows you to define what pixel value "bits" are alpha
and gain access to rendering calls that can paint with alpha blending and so
on. Writing a 3D engine is a lot different - you will be hand calculating your
own pixels and then you don't want to deal with XRender... XRender just will
allow you to set up a visual for a window so it has an alpha channel and know
which bits are alpha if you want a "Transparent window" in this case, but
otherwise you'd be hand-writing the pixel and thus XShmPutImage is your friend.
That's for local which is the vast majority of cases. XPutImage for remote.

> red/green/blue/alpha channels. AllocColor was used in prehistoric
> times when dinosaurs roamed the earth and VGA hardware was able to
> handle a maximum of 16, 32, or similar number of colors on screen, so
> each window registered which handful of colors it wanted to use, and
> each time you switched windows the X server loaded the window's colors
> into the hardware registered that corresponded to each possible 4, 5,
> or similar bits per pixel (and all other windows from other
> applications changed into weird colors).
> 
> Those days are long gone. It's safe to assume that modern hardware
> supports RENDER.
> 
> The bad news is that, when starting from scratch, it'll take at least
> three months to pour through RENDER's documentation (that's a very
> optimistic estimate, it took me much longer than that) before
> everything soaks into your brain, and you "get it".

No need. See above... :)

This is also why people make toolkits ... so you don't have to do this. People
who have poured over Xlib documentation decades ago write toolkits to abstract
these things...

> > Is this an appropriate way to set the color? Is there a more efficient way
> > to do so?
> 
> This is as efficient as it gets. Each function call is a round-trip to
> the X11 server.

This is not true if you mean each xcb or xlib function is a round-trip. The
alloc color is - but many.. in fact most Xlib calls are not round-trips.
Knowing which are and are not is a matter of experience or reading the code.

> > Slightly unrelated question: as someone completely new to Xorg and Linux
> > graphics in general, how do you deal with the lack of documentation for XCB?
> 
> There's nothing to document. XCB is just a thin wrapper around the
> underlying X11 protocol. Which explains why you are unhappy about the
> performance of AllocColor, you did not realize that what this does is
> send a request to the X server and wait for the response.
> 
> You need to find the documentation for whichever parts you want to
> use. For the core X11 protocol it's
> 
> https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
> 
> You will find a curious pattern of X11 requests specified in this
> documentation matching one-for-one with the xcb functions you're
> already using, and their parameters. And then the light bulb over the
> top of your head goes off.
> 
> The only thing that XCB really does on its own is the allocation of
> XIDs, but that's not too difficult to figure out. RENDER is here:
> 
> https://www.x.org/releases/X11R7.7/doc/renderproto/renderproto.txt
> 
> The RENDER requests documented there will also match, bit by bit, with
> the xcb_render* functions in xcb, and so on. Probably the stuff that
> is the least match is all the setup stuff, which is where you will
> find all the goodies related to the video hardware and how to decode
> which bits in a pixel correspond to which channel. But once you find
> one end of the thread in the header files the rest won't be hard to
> unravel.

I'd just advise avoiding XCB unless you have been around the X11 world a long
time and have some corner cases where you need to remove a round trip and it's
key for performance. It's easier. well written Xlib code can be very performant
if you just don't do excessive round trips if there is another way. E.g. use
XInternAtoms() instead of XInternAtom() to set up all your atoms in one round
trip instead of 10 or 20 or 100. Don't get things excessively (like
properties). If you need to get a property - defer it until later and not
every time a property change event comes in. If a property changes many times
you can avoid multiple fetches and just fetch the latest value "some time
later" etc. For things like rendering xcb will have really no benefits over
xlib.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com