Too much screen tearing

[Voroz]

Hi.

I'm having some trouble with input lag with vsync on. If i disable vsync my mouse sprite is much faster and not so sluggish, but i get aloooot of screen tearing. I will have a constant huge line covering 10% of my screen height moving up or down slowly. The higher fps i get the thinner the line will be, but it's always there, even at 1300 fps.

I don't get tearing problems in other games if i get high enough fps so i'm not sure what the problem is. I've also tried using setFramerateLimit to see if i can get a certain fps with less tearing, but setFramerateLimit just picks set FPS values that aren't really even close to what i told it to pick. For example one fps is 200, next is 250 no matter what i type in between.

Thanks for your time.

[Nexus]

Can you elaborate the "input lag trouble" when VSync is activated?

How do you implement your game loop?

[Voroz]

Well i don't know exactly what info you're after, but this seems like a common issue with using vsync.
If i would enable windows mouse cursor then i would see the mouse sprite, or item that i'm dragging being drawn a frame or so behind the windows cursor. It makes the mouse feel unresponsive and sluggish.

Many big games manage to bypass this somehow while still using vsync, but i don't know how. I never really experienced this much tearing in a game before either with vsync off, especially not with a very high fps.

edit: I remember actually that even in League of Legends the mouse was more unresponsive while using vsync.

[Hapax]

i would see the mouse sprite...being drawn a frame or so behind the windows cursor

I don't see how it's can be possibly any more than a frame behind. Are you not updating the position at least once per frame and drawing it every frame?

I remember actually that even in League of Legends the mouse was more unresponsive while using vsync.

If you figure out the problem, let them know so they can fix theirs 

Many big games manage to bypass this somehow while still using vsync, but i don't know how. I never really experienced this much tearing in a game before either with vsync off, especially not with a very high fps.

It's possible that some of the games you refer to are actually changing the hardware cursor instead of drawing a software one.

That being said, I'm not sure how sluggish a cursor can be when it's less than 1/60th (usually) of a second behind the hardware position. Remember too that the (current) position you're actually using inside the program is the one that you're drawing on that frame.

[binary1248]

VSync solves tearing issues, but judging by your description of the issue "huge line covering 10% of my screen height", this does not sound like it is exclusively due to tearing. Either blank frames are being drawn in unsynchronized frames every now and then or something is wrong with your code. If you are willing to share a bit of code, I'm sure people will be able to spot faults in it if any exist.

Also, you should really unlearn the habit of referring to what you are witnessing as "input lag". It is true that media and more specifically gaming media refer to it as "input lag", but as a developer you are capable of better understanding what is happening.

One of the things with 3D rendering APIs is that they work using command queues. You command the GPU to do things... in the future. How far in the future depends on the situation. Obviously, commands are only removed from the front of the queue once they have been completed by the GPU. Any attentive reader would now ask: what happens if I issue commands faster than they can be completed? Well... the commands start to back up, to the point where they can only be completed multiple frames in the future. Obviously the engineers already thought of this problem and imposed a limit to how large the queue can become. Issuing commands once the queue is full will just block your application code until there is space again.

So... now that you know that the "lag" comes from the rendering side and not the input side, it might be a bit more obvious how to fix it. Enabling VSync doesn't slow down the source of the commands - your code - it just slows down the completion of the commands - the driver and GPU. To slow down the source, you would have to enable the framerate limiter in addition to VSync. Some people say it should be set equal to the VSync interval, some people say it should be less, as always it all depends. Also, there is no universal way to probe for the VSync interval, so there's that...

If you are hellbent on truly getting as low of an input lag as possible, you would have to make input polling independent of the drawing. Contrary to popular belief, it is possible to have game engines run faster than they can draw if the hardware allows. In this case, input would be polled every frame with "unlimited FPS" and the engine state updated as well. The graphics and drawing would only take place every 1/60 seconds or however long it takes the monitor to refresh, so if the engine is running at 120 FPS, that would be every second frame. Doing this, operating system input events would be buffered for as short as possible and have their effect on the game state in as little time as possible. This, is minimal input lag, not that garbage perpetuated by the media.

Also, if you want your cursor drawing to completely bypass the 3D graphics pipeline, you would need a so-called "hardware cursor" (misnomer if you ask me). SFML does not support hardware cursors yet, but work is under way to get them implemented soon.

[Voroz]

I guess what i need to bypass the vsync problem is a hardware cursor then. I don't think i have any more delay in mouse movement than anyone else, but i might be more bothered by it .
I still don't get why i get constant tearing instead of the occasional tearing that i might see in another game, and i'm pretty sure i'm not doing anything weird in my code like you say, atleast not anything that would cause extra tearing, but i guess i'll just wait for hardware cursor support and enable vsync.

Thanks for your help.

[Hapax]

Is it possible that you're not calling clear() and display() every frame and only once?

[Voroz]

Is it possible that you're not calling clear() and display() every frame and only once?

no i'm doing that, and only once. Have you tried without vsync? To see if you experience alot of tearing aswell.

[Hapax]

Have you tried without vsync? To see if you experience alot of tearing aswell.

Tried what without vsync?
At this point, where you want people to test things, a complete and minimal example would be the best way to go. It makes sure that you're still getting the problem with minimal code and we get to test it and can compare.

[Jabberwocky]

Thanks for the post, binary1248.  Good stuff as always.

Also, there is no universal way to probe for the VSync interval, so there's that...

Would it be possible to do a really low tech measurement of the VSync interval?  Something like a simple draw operation, then a swap buffer followed by a glFinish, with a timer to measure?  You could maybe run it a few frames if this would help ensure an accurate result?

Also, you should really unlearn the habit of referring to what you are witnessing as "input lag".

Out of curiosity, how would you refer to this?  "OpenGL command queue overflow due to a mismatch of game execution speed vs. GPU speed which imposes a visible latency between user input and the rendered results commonly perceived and referred to as 'input lag' by gamers and the input media" seems like a bit of a mouthful. 

[Hapax]

I'd be happy with just being able to check if vsync has actually enabled 

Out of curiosity, how would you refer to this?  "OpenGL command queue overflow due to a mismatch of game execution speed vs. GPU speed which imposes a visible latency between user input and the rendered results commonly perceived and referred to as 'input lag' by gamers and the input media" seems like a bit of a mouthful. 

"Command Queue Overflow" sounds reasonable.