Vsync, double buffering, and smooth animation
Okay. I packaged it all up if anyone wants to actually see what's going on: test.zip. Before the huge post above I explain a little bit more about what is going on. Anyone with experience might be able to pick out what's up from my descriptions, thanks.
Quote:Original post by darknebula42
Okay. I packaged it all up if anyone wants to actually see what's going on: test.zip. Before the huge post above I explain a little bit more about what is going on. Anyone with experience might be able to pick out what's up from my descriptions, thanks.
It gives me this error: "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
BTW, did you remove the calls to glFlush() and glFinish()?
Yes I did. Hrm..I remember having this problem before. I'm using Visual Studio 2008, and maybe I need to include some kind of manifest file or something?
edit: I updated it, could you try it again. Sorry about that. Thanks!
edit: I updated it, could you try it again. Sorry about that. Thanks!
This time it worked.
I see what you mean, the tearing is very noticeable. Unfortunately, I can't think of anything else to suggest.
I see what you mean, the tearing is very noticeable. Unfortunately, I can't think of anything else to suggest.
I tried your test program - I can't see any tearing at all (although I did notice that the animation seems to "jump" ahead/behind occasionally). I think your problem simply lies with an imperfect timer implementation running the animation.
Screen tearing should look like this if it were happening (courtesy of mspaint).
Screen tearing should look like this if it were happening (courtesy of mspaint).
Quote:Original post by Hodgman
I tried your test program - I can't see any tearing at all.
...
Screen tearing should look like this if it were happening (courtesy of mspaint).
That's strange, for me the tearing was quite noticeable (like in your picture).
What could cause such a variation?
That demo runs in windowed mode which is typically single buffered (except in Aero).
That is instead of merely swapping a pair of hardware pointers the buffers have to be copied to screen in sync with the raster beam, something that is handled less than perfectly on just about any hardware I've ever seen. I guess you might have some luck manually polling the raster line and waiting for the bottom of the window like D3D 8/9 does, but I have no idea how this would interact with GL.
As far as I know the only way to completely eliminate tearing in windowed mode is to use YUV overlays..
That is instead of merely swapping a pair of hardware pointers the buffers have to be copied to screen in sync with the raster beam, something that is handled less than perfectly on just about any hardware I've ever seen. I guess you might have some luck manually polling the raster line and waiting for the bottom of the window like D3D 8/9 does, but I have no idea how this would interact with GL.
As far as I know the only way to completely eliminate tearing in windowed mode is to use YUV overlays..
Quote:Original post by Hodgman
I tried your test program - I can't see any tearing at all (although I did notice that the animation seems to "jump" ahead/behind occasionally). I think your problem simply lies with an imperfect timer implementation running the animation.
Screen tearing should look like this if it were happening (courtesy of mspaint).
That is actually how mine looks, exactly! And you can't take screenshots of it.
implicit: Very interesting information. So you're saying there really isn't such thing as a double buffered Windowed mode that works? I'll do some test with full screen and check out some more information. Thanks.
edit: Is this what you're talking about, implicit? Swap Control
edit2: I put it in full screen, with double buffering on and still have the same issues!
[Edited by - darknebula42 on June 24, 2008 4:35:19 PM]
Tearing happens because you end up with parts of 2 frames on the screen, and one frame is very different the the other. So you see a very obvious 2 pictures. If you are moving a set number of pixels each frame, and you aren't capping it, then a high frame rate will make tearing very likely, or very noticeable. If your movement is very smooth, and there isn't much difference between any 2 frames, you won't notice tearing as much.
Quote:Original post by Daaark
Tearing happens because you end up with parts of 2 frames on the screen, and one frame is very different the the other. So you see a very obvious 2 pictures. If you are moving a set number of pixels each frame, and you aren't capping it, then a high frame rate will make tearing very likely, or very noticeable. If your movement is very smooth, and there isn't much difference between any 2 frames, you won't notice tearing as much.
Yes, that's quite true. But when even moving at about 10 pixels per second it looks bad. And there is no way I shouldn't be able to not move 150 frames per second without tearing if double buffering is enabled.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement