Re: Still not understanding pixmaps vs RGBs

[Havoc Pennington <hp redhat com>]

"Lewin A.R.W. Edwards" <larwe larwe com> writes: 
> Mmm. Say, is there an equivalent to the Windows method of getting a
> window handle for the desktop? It would be good if I could draw direct
> to the background. I can't help but feel that I am losing performance
> in the fact that gdk is splitting up and queueing my large blit
> requests.

Sure you can get the root window (GDK_ROOT_PARENT() - you have to
include gdk/gdkx.h). If you draw straight to the root window using
multiple operations however, flicker or other ugliness will be
visible. e.g. this is why you can see the tiling.

All drawing is queued in X; so that's not an issue. The splitting up
is just that gdk_rgb_* uses one GdkImage of a fixed size, it converts
chunks of RGB data into the GdkImage format, writes GdkImage to your
window, then converts another chunk. Multiple operations to a
GdkWindow = funky ugliness.

By using one large image you use more RAM, and avoid multiple GdkImage
writes. However the main cost of a GdkImage write is pushing its data;
so your single write is going to be much more expensive than the
smaller writes were.

The standard trick to avoid multiple draw operations to a window is to
draw to a pixmap, then do the single operation of drawing the pixmap
to the window. And GTK 2 in fact does this for you.
 
But you can't avoid the intermediate GdkImage in any case, because
a GdkImage is how you assemble a bundle of pixels to be pushed to 
the server.

> Well, that's a parts/manufacturing cost, of course. The cheapest you
> can get these in the USA is from an SBC manufacturer like
> www.e-valuetech.com. Hardware of the type I described is about
> US$230 in one-piece quantity (64Mb RAM though).

Not really consumer-targetted is it. ;-)

Havoc