Re: Still not understanding pixmaps vs RGBs

[Havoc Pennington <hp redhat com>]

"Lewin A.R.W. Edwards" <larwe larwe com> writes: 
> Am I correct in my belief that when an expose_event occurs on a
> window, the server may take some default action (e.g. clearing to
> background color) before the gtk app gets a look at the event?

Yes that's right. Exactly what happens depends on the window
background, which can be a solid color, a tiled pixmap, or "None"
which means do nothing.
 
> What about a pixbuf? Will drawing a pixbuf also work in tiles?

I believe so, it may have changed in GTK 2, I don't really know.
The purpose of the tiles is to avoid creating large GdkImages.

In GTK 2 everything is automatically double-buffered though, so you
wouldn't _see_ the tiles most likely.

Since you have an embedded system you could always go in gdkrgb.c,
find the tile size, and change it. ;-)
 
> Does the X server ONLY work with video RAM? This system has 3Mb video
> RAM, which is not enough for two copies of a 1024x768x16 image. So I
> won't be able to create an offscreen buffer big enough to cover the
> entire screen unless the X server can use main memory for
> that. Therefore pixmaps are out :)

The server can fall back to main memory, but I'm told it has kind of a
dumb algorithm (it doesn't "swap out" things from video RAM, just puts
the first pixmaps to be created in video RAM).
 
> The system I'm using is a National Semiconductor Geode processor with
> a Cyrix 5530 companion IC. This is a unified memory architecture. All
> the RAM is on the same bus, including video RAM. The graphics
> "controller" is really just a DMA channel that squirts digital data to
> DACs or a digital LCD (or both), with some extra logic to generate
> sync pulses every [x] fetch cycles Very little in the way of enhanced
> features in it. It's fast enough in framebuffer mode, but I want to be
> able to change resolutions on the fly...

Yeah, you don't have the luxury of just figuring the Radeon will be
fast like the rest of us do. ;-)

Havoc