Re: [gtk-list] Flickering images on drawable

[Havoc Pennington <hp redhat com>]

Stewart John Moorehead <sjm@ux2.sp.cs.cmu.edu> writes:
> I am displaying some graphics on a drawable widget, one using 
> gdk_draw_gray_image is a background map which changes infrequently.
> The other is a circle (using gsk_draw_arc) which will change position 
> every 1/10 of a second. (I have included a code fragment below on how 
> I am doing this).
> 
> My problem is that the circle flickers on the display, and this display
> is really loading the CPU. I get both problems even if I do not update

I would suggest the following.

 - Create a GdkPixmap, and draw your background to that only once.
   This avoids the overhead of sending the RGB data to the X server.
 - When you update the drawing area, copy _only_ the region of the 
   background pixmap that used to contain the circle, over the top of the 
   circle, thus erasing the circle
 - Then draw your new circle
 - You'll need an expose event handler also, which would copy the
   backing pixmap to the exposed area, and then draw the circle.

If the circle still flickers, you might need a double buffer as in the
scribble example; I would make your buffer the size of the smallest
rectangle that encloses both the old and the new locations of the
circle, copy in the corresponding part of the background pixmap, 
draw your new circle, then copy the buffer onto the drawing area.
As another optimization, if the old and new circles don't overlap,
there shouldn't be any visible flicker anyway, so you can only create
the double buffer if your old and new circles overlap.

In GTK 1.4 this flicker will go away automatically though, so you can
look forward to that nice feature.

If you still can't keep up with the rate of change (i.e. your updates
take longer than 1/10 second), you might need to drop some frames in
order to keep things looking smooth. I remember there used to be an
example of doing this in the Java tutorial, I don't remember the exact
algorithm, but it should be pretty easy to figure out. Just drop
frames instead of letting a backlog accumulate, and use a timeout or
the inherent rate of data delivery to hold the rate of display
constant.

Havoc