Re: gdk double buffering

[Patrick <pabos glypsube org>]

Below.

On Wed, 2003-03-12 at 15:20, Soeren Sandmann wrote:
> Wouter van Kleunen <w a p vankleunen student utwente nl> writes:
> 
> [GDK event compression discussion ommitted]
>
> > 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

I'm in the preliminary stages of designing a multipurpose x11*-based canvas right now (ie. learning x11)
and this surprises me. Does anybody know if the "SYNC" extension was added in 4.3 (I'm not seeing
anything on xfree86.org)? Its been quite sometime since I did low-level
graphics programming but my recollection is that back in the DOS days of
386 protected mode assembler programming several relatively introductory
demo tutorials described how to do all drawing in memory and then
blitting changes to the screen as fast as possible on the refresh
interrupt (or trying to synchronize with the monitor's refresh signal
first if no refresh interrupt was available). With x11's asynchronous
design I could see that exposing the signal to applications could be
problematic but I would have thought x11 itself would be capable of
delaying its draws until the refresh signal?

I've searched for more information on SYNC and I found someone's diary
from 2001 talking about the same problem which mentions the kernel
integration problems (http://www.linux.org.uk/diary/april-2001.shtml)
you've mentioned. Is this because each OS xfree86 runs on will require
different interrupt interface system calls? (In my ignorance of another
standard I imagine that would have been standardized in some UNIX
compatibility standard like POSIX - or is that at the shared library
level?) I suppose each card would need to setup the interrupt in its own
peculiar way which might require a custom kernel module per card? Or is
it hard to trigger user-space code from a kernel interrupt handler with
real-time priority?

Hmm... just wondering out loud.


* I just recalled reading somewhere once that some people are picky
about how to refer to x windows - or is that x window? or x11 window? or
xfree86?; what's the standard practice?