Re: Speed of Gdk-Pixbuf Vs. GdkRGB

[John Cupitt <john cupitt ng-london org uk>]

Hi,

David J. Singer wrote:
> My question is, if drawing speed is an issue, is it faster to use the slightly lower-level
> GdkRGB method rather than the Gdk-Pixbuf one?  More generally, how does the 
> Gdk-Pixbuf stuff rate in terms of drawing speed compared to GkdRGB?

They are equivalent (AFAIK). You only need the lower-level stuff if you want to avoid loading the whole image into memory, or I guess if your image is procedurally generated. It should be easy to benchmark I guess.

> On a related point, I usually define a backing pixmap in a 'configure' callback, draw the
> graphical content into the pixmap, then copy it to the drawing-area in one go in an
>  'expose' callback.   (based loosely on the "simple example program using GdkRGB" in 
> the Gdk docs).  Is this still the best way to go for fast, flicker-free graphic updates?

Gtk now does this for you. 

Before calling your expose callback, gtk allocates an offscreen pixmap the size of the expose area, redirects gdk_* to that off screen pixmap, calls your expose handler, then copies the offscreen pixmap to the display. 

Smarter expose compression makes this acceptably quick in most cases: exposes are batched up and your handler will be called with the bounding box of the area to be repainted. If this is too coarse, you can get the exact minimal list of dirty rects out of the expose structure.

The downside is you must only ever paint in the expose handler. For video stuff, you need to call gtk_widget_queue_draw_area( widget, x, y, w, h ) when a frame comes in to get a repaint queued for the right part of your widget.

John