Re: Using GdkPixmaps for storing static image data

[Havoc Pennington <hp redhat com>]

"J. Ali Harlow" <gtk-list optosun7 city ac uk> writes:
> On Thu, 22 Mar 2001, Havoc Pennington wrote:
> > Basically a GdkPixmap is a server-side image data buffer, and isn't
> > all that appropriate as a place to store image data loaded from disk,
> > among other reasons because it makes you think about the visual/cmap
> > of the workstation's video hardware.
> >
> > Anyhow, in GTK 2 the GdkPixmap code still works but you no longer need
> > to use it in newly-written application code.
> 
> That's quite a statement! Perhaps I've missunderstood.
> 
> In Slash'EM (not-yet-cvs) we maintain a drawing area which is basically a map of
> your surroundings, built up of tiles. These tiles are stored in a tileset, which
> (depending on the mode) can be stored in a Pixmap. This makes drawing to the
> map an efficient operation since both the tileset and the map are server-side
> and the drawing commands end up being a series of CopyArea requests. If we were
> to use Pixbufs we would presumably end up with a series of PutImage requests
> which would be a _lot_ slower.

Well sure, but this is a non-issue for toolbars. GdkPixmap is intended
for exactly this kind of server-side buffering when performance is
important. For some little toolbar icons, there's no point
complicating things.

> One of the things I think Gtk is missing is a function to go from disk to
> image. You can use the API to go via pixmaps, but that's a little
> crazy :-)

In general I don't think there's too much reason to use images - 
it's just too hard to handle all the visual-specific details.
So Pixbuf is in that sense a GdkImage replacement.

> One of my remaining jobs is to write a routine to copy from pixbufs to images
> to solve this.

This code should already be in pixbuf_render_to_drawable(), it draws
to a pixmap by first going to an image, then to the pixmap, IIRC.

Havoc