Re: speeding up redraws

[Owen Taylor <otaylor gtk org>]

<nuke@bayside.net> writes:

> i'm looking into speeding up the redraws in gtk. i'm pretty sure most of
> the time is spent loading the X server by clearing and redrawing entire
> widgets when only part of them needs the draw. honestly, i don't know how
> a toolkit can tell the difference. this kind of thing happens most
> noticably on scrollbars, buttons (especially in testgtk- try opaque moving
> a window over those buttons and watch them blink and redraw), and text
> that is actually being modified but is on the same line as text that is
> (selection, inserting).

There are two things you are discussing here, speed and appearance.
These are somewhat separate (though related) issues, and I think
your complaint is more with the second one. But I'll cover
both.

The most important thing to speed up GTK's redrawing is expose event
compression. If you opaque-move a window over a GTK window, the X
server will probably queue 5-6 narrow rectangles into GTK's queue
before it can process the first expose event. If these rectangles are
handled one-by-one it must redraw each button (etc.) 5-6 times. If it
instead combines them into one big rectangle, it only has to do this
once.

The trickiest part of this is figuring out when to combine areas
or not. (A simple bounding box can increase the expose area
greatly - though Xt appears to do this) Various solutions
have been proposed - for instance microtiles.

Expose event compression is a global thing that needs to be
added to GDK, not to individual widgets. 

But no-matter how fast things are drawn, if you clear then redraw,
there is always a chance that the cleared state will be briefly drawn
on the screen, causing flicker.

Flicker avoidance can be handled several ways:

 - Draw each pixel only once. If no clearing is done in advance,
   then no flickering will happen. But this can complicate the
   display code quite a bit - you need to explicitly fill any
   areas that don't get drawn otherwise with the background
   color - and is actually impossible when you text is involved.
   (The clear isn't necessary when handling expose events, but the
   same drawing code is used for handling other cases like resizes 
   or changes of state where non-empty regions can become empty regions)

 - Draw only the affected regions. If you only redraw the portions
   within the expose rectangles, then no flickering will happen
   on exposes (though this won't help resizes). You can either
   do this by doing the clipping yourself (complicated), or 
   by setting the clip region for the GC's you are drawing with.
   (Somewhat expensive because something like a button may use quite
   a few different GC's)

 - Use a backing pixmap. Draw everything to the backing pixmap,
   then copy the result onto the screen. This is often the
   simplest method, but is expensive in terms of server memory.

So, that may give some idea of the issues involved, and where
you might start.

Regards,
                                        Owen