gdk pixmap vs gdk pixbuf

웹에서 찾아본 결과 window X system에서 디스플레이하는 방식의 차이 같네요.

http://mail.gnome.org/archives/gtk-perl-list/2006-March/msg00036.html

...
The X Window System uses a client/server architecture in which the screen and windows on it are managed by a window server, which deals with the display and input hardware. This server provides windowing services to client applications. (Many people think X's client and server names are backwards, but when seen from the point of view that the server provides windowing services to client applications, it makes sense.)

The client and server are not only separate processes, but may be on different physical machines. Because of this, the latency for a round trip to the server can be quite large, and the X model for many operations is designed to minimize this. That's where graphics contexts and pixmaps come from. A graphics context ("GC") is a server-side resource that contains information on how to perform drawing operations. The client has a handle which refers to a particular GC, and passes the handle with drawing operations. This keeps the client from having to transmit all of that information with each drawing command.

Similarly, image data can be stored in "bitmaps" (1-bit images, or maps of bits) or "pixmaps" (maps of more-than-one-bit pixels, or pixel maps). These are stored on the server, at device bit resolution and bit depth, and this can be manipulated quite quickly. Operations like $drawable->draw_pixmap() involve copying only the command information from the client to the server, because all of the bits are already on the server. These are stored in the server's memory.

So where does a GdkPixbuf fit in? Recall that the pixmap is stored on the server at device resolution and bitdepth. This means that if you want to change just one pixel, you have to do a round trip, which is expensive. Also, you'll have to deal with the image data at the server's bit depth, which could be anything -- 888, 565, indexed pseudocolor, etc, maybe involving dithering. Because this is a royal PITA, the gnome guys came up with GdkPixbuf, which is a simple 24-bit RGB or 32-bit RGBA image buffer stored in the *client*, which can be dithered and transferred to the server as needed. (The RENDER extension includes features to make this more efficient.)

GtkImage provides a way for you to set the source data directly from a pixbuf --- $image->set_from_pixbuf($pixbuf) --- so you could avoid the pixmap/mask stage.

You can also place a GdkPixbuf into a GnomeCanvas, which gives you more efficient rendering of the changed portions. You could use GnomeCanvasItems for the selected objects text overlays and that sort of stuff, along with scaling and other fun tricks.

You'll probably want also check for reference leaks in your code to make sure you're not piling up pixbufs.

If using a Canvas is not practical, you can probably drop a few steps by writing some of the more compute-intensive display stuff in C --- if you already have custom C code, then binding your own C widgets to gtk2-perl should be no problem. You could do stuff like render much smaller pieces from the source data and blit them exactly where they need to go in the master pixbuf.

...