I have written a program that loads an object which you can move around in space via keyboard and mouse input. It’s a simple Win32-application. But I just can’t get rid of tearing effects which are especially visible in left-right movement.
I already tried switching VSync on and off using wglSwapIntervalEXT(n), but that doesn’t make any difference. Then I thought that maybe the keyboard input interrupts the drawing function, so I changed the code to make this impossible. This isn’t causing the tearing either and debugging also tells me that the input doesn’t interrupt drawing.
I tested it on three computers:
- Windows XP, Intel 82852/82855 GM/GME -> TEARING
- Windows XP, Intel G33/G31 Express -> TEARING
- Windows Vista, Intel G33/G31 Express -> NO TEARING
So it seems that the problem is XP-specific. Does anyone have any ideas what might be the cause of this problem?
Thanks in advance for any help!
If you’re doing double-buffering, as you should, test your app on a PC with a decent gpu.
I’m using double buffering of course. As written above it works under Vista even though the graphic card sucks. Apart from this, I want the app to work properly on comuters with bad graphic cards.
Maybe try using glFinish? Otherwise you might rework it so that it only updates the position on screen every 2 or 3 frames.
glFinish has nothing to do with horizontal tearing.
I already tried switching VSync on and off using wglSwapIntervalEXT(n), but that doesn’t make any difference
That is a problem. Normally, as you increase n, you slow down the refresh rate, so you should notice at least that.
With a 60Hz display, n=60 means 1FPS.
If this is not the case, the vsync is overriden by the driver. No experience with Intel, but Nvidia and AMD provide advanced settings to users such as ‘force vsync on’, ‘force vsync off’, ‘let application decide’.
Only with that last setting the wglSwapInterval command has effect.
Vista has a different model, ie. with Aero vsync is always on.
Absolutely true, but where I’m coming from is that it will force the GPU to sync which may help ameliorate the effect.
Thanks for your help! In the Intel-settings there’s a switch called “asynchronous flip”. Turning this on/off still makes no difference.
I tried using wglSwapIntervalEXT(n) with high values for n, like you said ZbuffeR. It really doesn’t change, no matter if “asynchronous flip” is on or off. That means that something went wrong by loading the OpenGL extension, I guess. I use GLee and GLEE_WGL_EXT_swap_control returns true. I’m confused…
That means that something went wrong by loading the OpenGL extension, I guess.
No it doesn’t. If you get a function pointer (that is, calling it doesn’t crash), then that’s all extension loading can do for you. If the function doesn’t do what you want, that’s not something that extension loading can help you with.
As already stated this is probably vsync related.
vsync on PCs tends to have driver controls that override what your application does, so while it looks like you’re doing the right thing with swapinterval, as “ZbuffeR” has said you need to check the desktop driver settings/overrides.
There is a chance that it’s a driver bug so try updating your drivers or rolling them back to an earlier version (WHQL).
There’s a remote chance that it’s not a vsync problem, perhaps you could try pausing the rendering at a random interval and taking a look. Quite what would cause this is anyone’s guess, some wacky scissor/swap abuse or equivalent.
Those Intel settings are strange. They don’t seem to change anything.
I realised that wglSwapIntervalEXT(n) only accepts 0 or 1 as argument and returns false for higher values.
I deactivated Aero in Vista and now the tearing effects appear here also, so it’s definitely a VSync-problem. So it’s the really the way like ZbuffeR said.
Is there a possibility to force VSync out of the application? Or is wglSwapIntervalEXT the only thing one could try?
At least I know what causes the problem now. Thanks to everybody for helping me out!
I also faced the same problem of tearing effect when rendering more than 60 frames in a second.
Even if u displaying 100 frames( 100 swapbuffer ) in a second, monitor copies front buffer to monitor based on monitor refresh rate.
If monitor refresh rate is 60, pixels from your front buffer will be copied to monitor only 60 times.
I solved this issue by limiting swapbuffer calls exactly same as that of monitor refresh rate. Now we are getting very good real time feeling without any flickering.
From what I’ve seen, it appears that vsync is implemented properly under Vista/7 but instead as a busy wait under XP; perhaps the potential slowdown caused by a busy wait was sufficient for most driver writers to avoid writing vsync code at all.
Beg to differ slightly : some driver writers were doing the good thing on XP (nvidia), some were doing the wrong thing with a busy loop, some were doing the wrongest wrong thing by not doing it at all.
some driver writers were doing the good thing on XP (nvidia)
I didn’t notice this with my 6200, 7050M or 9500GT. Busy wait on XP with all of them. Under 7, properly implemented with the 9500GT.
The Intel GMA 900 netbook I have, it doesn’t vsync at all under XP, only Mint Linux.
AFAIR on my old 6800+various drivers, I saw busy wait only when doing vsync+glFinish(). vsync alone did not busy wait. Well YMMV I guess.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.