I’m using the SDL OpnGL library on Linux. When I sawp buffers during animation,
there is a tearing effect on the screen. Top half of the screen is slightly
shifted away from the bottom half like this:
(let us assume there is a square on screen)-------------------------
| |
| ***** |
| *****(tearing) |
| ***** |
| ***** |
Could you please tell me if there is a function in the SDL library which can
help me overcome this tearing effect by synchronizing my frame rate with the
vertical retrace rate, or if there is some Timer code that can help me?
I’m using the SDL OpnGL library on Linux. When I sawp buffers during
animation, there is a tearing effect on the screen. Top half of the
screen is slightly shifted away from the bottom half like this:
(let us assume there is a square on screen)
| ***** |
| *****(tearing) |
| ***** |
| ***** |
Does the tearing always happen in the middle of the screen? (That would
mean that the the driver does sync to the retrace, but screws up the
actual flipping/refreshing. For example, Utah-GLX drivers can’t do
hardware pageflipping, so they blit the back buffer into the display
buffer instead. If such a driver would attempt to sync with the retrace,
but doesn’t consider the delay caused by the accelerator command buffer,
the actual “flip blit” will start way too late, causing tearing in
different areas of the screen depending on how heavy rendering you’re
doing.)
What 3D card, X server and GLX/DRI driver are you using?
Could you please tell me if there is a function in the SDL library
which can help me overcome this tearing effect by synchronizing my
frame rate with the vertical retrace rate, or if there is some Timer
code that can help me?
No, SDL doesn’t even explicitly support retrace sync - it just "happends"
to do it if the underlying API does it. It’s not even possible to do
retrace sync without dirty hacks on some targets. Where it’s supported,
SDL_Flip() automatically synchronizes with the retrace - or relies on the
hardware to do a “delayed” flip, in which case the next attempt to lock
the screen surface will indirectly result in retrace sync, as the lock
will have to wait until the back buffer is flipped out of display.
//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 Friday 28 September 2001 12:00, nishal at iitk.ac.in wrote:
Any idea why? Seems like Linux users are expected to prefer "fake"
framerates to solid animation… heh
//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 Friday 28 September 2001 16:46, Ryan C. Gordon wrote:
What 3D card, X server and GLX/DRI driver are you using?
Just for reference, if you’ve got an Nvidia card and Nvidia’s drivers,
you can export __GL_SYNC_TO_VBLANK=1 …
No, frame tearing does not always occur in the middle, so I suppose it isnt
synchronized. I’m using an nVIDIA RIVA TNT2 M64, XServer version 4.0 and nVIDIA
provided Kernel and GLX Drivers.
By the way I did try to export __GL_SYNC_VBLANK=1, but Xserver crashed. I did
get some advice from the OpenGL forum but that was connected to Windows OpenGL.
Please give me more ideas.
Thanks,
Nishal.> On Friday 28 September 2001 12:00, @Nishal_Thomas wrote:
I’m using the SDL OpnGL library on Linux. When I sawp buffers during
animation, there is a tearing effect on the screen. Top half of the
screen is slightly shifted away from the bottom half like this:
(let us assume there is a square on screen)
| ***** |
| *****(tearing) |
| ***** |
| ***** |
Does the tearing always happen in the middle of the screen? (That would
mean that the the driver does sync to the retrace, but screws up the
actual flipping/refreshing. For example, Utah-GLX drivers can’t do
hardware pageflipping, so they blit the back buffer into the display
buffer instead. If such a driver would attempt to sync with the retrace,
but doesn’t consider the delay caused by the accelerator command buffer,
the actual “flip blit” will start way too late, causing tearing in
different areas of the screen depending on how heavy rendering you’re
doing.)
What 3D card, X server and GLX/DRI driver are you using?
Could you please tell me if there is a function in the SDL library
which can help me overcome this tearing effect by synchronizing my
frame rate with the vertical retrace rate, or if there is some Timer
code that can help me?
No, SDL doesn’t even explicitly support retrace sync - it just "happends"
to do it if the underlying API does it. It’s not even possible to do
retrace sync without dirty hacks on some targets. Where it’s supported,
SDL_Flip() automatically synchronizes with the retrace - or relies on the
hardware to do a “delayed” flip, in which case the next attempt to lock
the screen surface will indirectly result in retrace sync, as the lock
will have to wait until the back buffer is flipped out of display.
//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 -’
Crashed or froze? Either way, it seems like you have a broken driver…
I don’t think you can get away with less than somehow fixing the driver,
configuration, or whatever turns out to be broken. That driver “feature”
(as if it shouldn’t always be done by every driver!) is the only way
to get retrace sync on X, short of polling the VGA register directly. (I
have a hack that does that, and also checks the TSC to deal with the
frequent missed retraces, but you don’t want to use that unless you’re
building a custom system or something…)
//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 Friday 28 September 2001 19:27, nishal at iitk.ac.in wrote:
No, frame tearing does not always occur in the middle, so I suppose it
isnt synchronized. I’m using an nVIDIA RIVA TNT2 M64, XServer version
4.0 and nVIDIA provided Kernel and GLX Drivers.
By the way I did try to export __GL_SYNC_VBLANK=1, but Xserver crashed.
From: david.olofson@reologica.se (David Olofson)
To:
Sent: Friday, September 28, 2001 10:02 PM
Subject: Re: [SDL] Frame tearing during vertical retrace…
On Friday 28 September 2001 19:27, nishal at iitk.ac.in wrote:
No, frame tearing does not always occur in the middle, so I suppose it
isnt synchronized. I’m using an nVIDIA RIVA TNT2 M64, XServer version
4.0 and nVIDIA provided Kernel and GLX Drivers.
By the way I did try to export __GL_SYNC_VBLANK=1, but Xserver crashed.
That one doesn’t work with me either. When I tried it, (on my TNT), the
system kind of froze. I later discovered that it just waited indefinitely
for a vblank; once or twice a vblanc actually was detected, but two frames
per minute is not really what I had had in mind
I guess this is a problem with the latest nvidia drivers. A pity that there
are no open-source ones.
