Re: gdk double buffering

[Federico Mena Quintero <federico ximian com>]

On Thu, 2003-03-13 at 11:24, Wouter van Kleunen wrote:

> When you move a window, xfree also seems to do something like:
> 
>   1. Move window
>   2. Clear under laying window. 
>   3. Send message
>   4. return
> 
> Main event loop:
>   5. get message from client
>   6. draw 
> 
> And alot of time will pass between the clearing and the drawing. Now that is 
> not very nice :-). 

You can't really control how much time will pass --- the kernel may
simply not schedule your program until some noticeable time after the
"Send message" stage.

But rather than micro-optimizing the event loop (or doing scary things
like synchronizing the kernel and the X server and applications), you
can do very useful work in some areas.

For example, you could make GDK pay attention to VisibilityNotify events
so that calls to drawing functions do nothing if a window gets
FullyObscured.  Or you could figure out if there is a way to get a
window's real visible area from the X server without doing egregious and
non-atomic things like walking the window tree --- then you could stick
that into gdk/x11/gdkwindow-x11.c:
gdk_window_impl_x11_get_visible_region().  Then make all the drawing
calls pay attention to that.  This would help a lot, say, when you have
a terminal scrolling a lot (think of a compilation cycle) and when the
terminal's window is not even in the virtual desktop you are in --- my X
server gets really jerky when VTE scrolls a lot in the background, for
example, and it is a 1 GHz machine...

Remember that most of the speed problems in GUIs are perceptual, and
hard problems like synchronizing the X server and apps are best left to
the X server itself.  Once Xfree gets real transparent windows it will
most likely keep backing store of its own for all windows, so a lot of
these problems will be solved automatically.

I haven't found the time to use xmon or some other X traffic sniffer to
see if GDK's drawing innards are doing something that could be
optimized.  Right now it creates and destroys a GC for each temporary
pixmap used for double buffering; I don't know if that creates X traffic
or if Xlib is doing caching for us --- maybe it would be better to share
a single GC for all drawables with the same depth?

  Federico