Ah, my favourite subject again! 
[…]
Is there a way to precily tell when the screen shows what you want
that you show?
No, not with any mainstream Linux drivers apart from svgalib, AFAIK. (And
I would say you shouldn’t rely too heavily on svgalib’s retrace sync
either… See below.)
[…]
Now here is my question: Is there a way to find out when exactly
something is presented on the screen with SDL?
No. In fact, no mainstream API I know of can tell you the exact display
time for each frame. They can’t even tell you how many video refreshes
have elapsed, or whether you’ve missed any!
The closest you get is when using h/w double buffering
(SDL_HWSURFACE | SDL_DOUBLEBUF), which will cause SDL to retrace sync the
flips, provided it’s supported by the underlying API. On Linux, that
basically means svgalib, or patched drivers.
From the archives I
understand there is no direct access to low level vsync information,
but maybe you can suggest some other solution. Thanks!
Either hack your drivers (and make sure SDL makes use of your hack), or
perform retrace sync on the application level.
Either way, it’s a bit hairy to get right, since you can’t rely on IRQs
these days. All you’ve got is a single bit in a VGA legacy register
(which may not work in non-VGA modes on some cards!), and this bit is
active only during the actual retrace. If you miss it while polling, you
drop a frame, and without looking at some timer (TSC, SDL_GetTicks() or
something), you won’t even know about it!
As if this isn’t bad enough, polling for real time events (CPU hogging!)
defeats the purpose in any multitasking OS. The scheduler will think that
you’re just doing some long winded internal calculations, and assumes
that it doesn’t matter much when you get to do it. Of course, that
means that you’ll lose the CPU for hundreds of ms - and miss several
retraces - as soon as any other process has something to do.
My suggestion would be to do the retrace (or “vblank”) polling in a
background daemon (that effectively replaces the kernel idle thread),
grab the current time before and after each “hit”, and feed the data into
a PLL.
You should measure or otherwise figure out the actual refresh rate during
initialization. The PLL will basically just lock a synthetic “frame
clock” to the actual refresh rate, and in my experience, you could get
away with no more than one correctly timestamped “event” every few
minutes. It’s not like the polling thread needs to hog the system to
extract useful data. 
Then, set up the Linux RTC device at a fixed rate - significantly higher
than the video frame rate for accuracy - and hook a high priority
SCHED_FIFO daemon up to it. The daemon should communicate with the
retrace PLL, and stay in sync with the retrace that way.
Another, much simpler, but more drastic method would be to install
RTLinux or RTAI, and set up one-shot thread that wakes up right before
each retrace is expected (just a few tens of ?s should do), polls until
the retrace bit changes, writes something nices to an RT FIFO and then
goes to sleep again, waiting for the next retrace. RTlinux and RTAI
reprogram the PIT (or APIC if present) for accurate “dynamic” timing, so
you’re not restricted to 64, 128, 256,… Hz or anything like that, as
you are with the RTC. And of course, RTlinux and RTAI provides the kind
of scheduling latency guarantees need to pull this method off.
Regardless of sync method though, there’s still one major issue: Page
flipping. Without h/w page flipping, you’re going to have a hard time
doing smooth and tearing free animation.
“Half buffering” is a handy trick if you can’t find a driver that
supports h/w page flipping. Sync in the middle of the refresh, render the
upper part of the screen, sync to the retrace and then render the lower
part of the screen. Loop. This can work very well, but of course, you
need fillrate to keep up with the refresh rate.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 17 September 2002 06:04, Gijsbert Stoet wrote: