Re: Still not understanding pixmaps vs RGBs

["Lewin A.R.W. Edwards" <larwe larwe com>]

Hi Havoc!

>   - GdkWindow: a server-side set of pixels that are visible onscreen,
>                in hardware display format


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?

>   - GdkPixbuf: in the separate gdk-pixbuf library for GTK 1.2,
>                included in GTK 2.0; an RGB or RGBA format set of
>                pixels on the client side. 
>
> The gdk-pixbuf library contains fast scaling code. If you don't need
> the scaling just using the raw RGB arrays as supported by GTK 1.2 is
> OK.


I want to at least try someone else's scaling :) I thinnnnnnkkkk I will 
move to GTK 2.0.

> There are no drawing primitives (gdk_draw_*) for Image or Pixbuf,
> because the drawing primitives are implemented on the server side.


That's OK. I don't need anything that way. I have my own font and 
polygon engine (from previous incarnations of the same system).


> You said you saw a "tile" effect as things were copied - I believe
> GdkRGB works in tiles. The way to keep that invisible is to create a
> screen-sized pixmap, draw to that, then copy the pixmap to the target


What about a pixbuf? Will drawing a pixbuf also work in tiles?


> window, and free the pixmap. You want to free a huge pixmap like that
> as soon as you use it or it will eat up your video RAM and slow
> everything down.


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 :)

> Creating pixmaps and copying them to windows is pretty darn cheap, it
> shouldn't be an issue. All remotely recent graphics cards can do the
> copy in hardware.


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...

--
-- Lewin A.R.W. Edwards (Embedded Engineer)
Work     http://www.digi-frame.com/
Personal http://www.larwe.com/
Tel (914) 937-4090 9am-6pm ET M-F