Re: gdk double buffering

[Soeren Sandmann <sandmann daimi au dk>]

Wouter van Kleunen <w a p vankleunen student utwente nl> writes:

> On most expose events however, it's not enough to redraw one x11 window. But 
> several expose events will come in back to back. These individual expose 
> events can be double buffered. But if the time between the events is to large 
> that will also be seen as "flicker". An example of what happens now:
> 
> -- Gtk Application --
>   expose event1 
> 	1 buffer is created 
> 	2 widget drawn to buffer 
> 	3 buffer blitted
> 
>   expose event2 
> 	1 buffer is created 
> 	2 widget drawn to buffer 
> 	3 buffer blitted

Actually, gtk+'s drawing is more like this:

        1 read all expose events, combining them to form a pixel exact
          "invalid" region in each window.

        2 for each window

                2a  create a buffer the size of the bounding box of the
                    invalid region

                2b  draw all widgets that use this window to the buffer

                2c  blit the buffer

So the effect is to combine successive expose events. Note that many
gtk+ widgets, in fact _most_ gtk+ widgets, do _not_ have their own X
window. Instead they draw on their parent's window (or the window of
the closest ancestor that has its own window).

for example, GtkButtons do not have their own window, so in a typical
dialog box, the buttons will draw directly on the toplevel
window.  

With the double buffering algorithm above, this means that all widgets
that do not have their own window will be drawn to the same pixmap and
blitted to the screen at the same time.

> This will not solve all problems. This is because X can't guarantee that all 
> operations happen in one frame. This is large problem. Because how hard the 
> widget set library tries, it can't ever guarantee that a operation is flicker 
> free. 

The algorithm above does not guarantee that operations on two
different windows happen atomically, and also X does not guarantee
that the blit happens within the vblank period, so you will see some
tearing.

> What we want is that operations are atomic. We know atomic operations from 
> databases. Atomic operations in databases are handled with transactions. So 
> handling events in X should be done in a way of transactions. Here is how i 
> see it:

There is an X extension called "SYNC" that allows a client to
synchronize within the X server its drawings to events. Such events
can be generated by other applications or by a timer or by the vblank
period starting. You probably want to read up on this extension.

Unfortunately, XFree86 does not currently offer a vblank event
sourcem, so it is actually not really possible to synchronize to
vblank.

Extending XFree86 to do this apparently require cooperation from the
kernel.


Søren