VSync, latency and transformed objects, triple buffering

[HerrKhosse]

Basically, I'm trying to further understand the pro&cons of vsync, what I figure is, both ways there are problems.
To keep it simple:
- VSync produces very noticeable latency, I don't completely know why and I don't think I really need to understand why.
- Without Vsync, you get very bad distortions and there will be no such thing as fluent moving pictures.

I'm currently trying to do a "simple" 2D RTS, very basic graphics, very pixelated. I'm using both hardware and software cursor atm, to get a feel of latency issues.
Without VSync, there is ALMOST no latency whatsoever between rendering and mouse updates. But you will have problems with stark in contrast edges and forms when they move.
Basically, I'm rendering a big Texture (THE background) in an ortho Projection and scroll via glTranslates in modelview, that seems to be pretty much the way you normally do something like this

When I'm scrolling decently fast, the images gets distorted like this:



Which makes sense, because it is not vertical synced. It's very clearly noticeable on straight objects and less so where are no clearly visible forms.

So that's my first observation, I don't think this is any news to people who have done something in OpenGL Just thought wouldn't hurt for newcomers if they are wondering.

When having VSync on, the picture seems pixel-perfect, no distortion, nothing which catches the eye. Altough I'm back to these horrible latencies.
Basically, my question is, if the Mouse updates are affected by the vsync, again, I don't really exactly know how the Mouse class is handled in LWJGL, but when I'm trying for example to solve a simple Multi-Selection in my 2D RTS, with VSync, it would end up like this when capturing a single frame:



I'll begin in the top left, drawing a rectangle(multi-selection) over all my objects, now... the cursors in this case are a hardware-cursors, so they, of course, are not affected by latency, but the selection-rectangle obviously is, so, because of latency, my selection will always be slower than my mouse and drag behind.

My question would be: if I call a Mouse.getY() and getX(), in this Moment, would I get the position of the red or blue cross returned?
What I suppose is that the Mouse updates are not affected by the VSync, so I can actually ignore the fact that the rectangle will get drawn behind as long as the right objects will get selected.

It would be visually less responsive, but not really affect the speed of the players input.
I absolutely understand why its pretty much always optional to enable vsync, it's just another problem which doesn't seem to be completely solved at the time.

Regards,
HerrKhosse

[CodeBunny]

I believe that V-Sync is a purely graphical effect, and as such, your program's logic runs at normal speed, so yes, the returned mouse coordinates are accurate. I haven't researched V-Sync that much, however, so do some tests.

[HerrKhosse]

Well, I don't really currently have an idea how to know for sure, thats why I asked it here in the first place.
My guess is, that some people have a better understanding and can clear this up.

I have the same suspicion as you, I just wanted to verify it

[kappa]

Are you running in windowed mode or fullscreen? as I understand it vsync only works in fullscreen mode, since this allows the app to control the screen page flipping.

[HerrKhosse]

Thanks for the reply.
Ah, good to know. So basically this is a restriction through... the OS ? Windows?
hmmm... altough it makes sense that its hard to update several portions of the display at different rates, so... well... I guess thats that

I'm using fullscreen-mode.
VSync is working properly in that sense that I have no tearing what so ever.
My worries are due to the very noticeable latency it produces

I did some "serious testing" as CodeBunny commanded me to
I'm rendering software and hardware cursor at the same time and observed if

if (Mouse.getX() == 0)
System.exit(0);

would trigger the instant the hardware cursor is there or until it seems like it gets delayed a few milliseconds.

And my, extremely scientific, test result is that: No, it seems that the Mouse Position polls are NOT affected by Vsync and indeed, mouse behaviour is absolutely accurate, altough ofc. any software rendering itself will get delayed. Which is something I can live with.

I still would prefer it if some who knows it better can ensure me thats the way it works and its not my most likely very faulty perception.

[HerrKhosse]

On another note: I've read up a bit about triple buffering and am very amused at most of the discussions I immediately get through Google.
Anyway, I wondered if I'm overseeing something, thou it looks like the Display Class has no setTripleBuffering Method Maybe I'm looking in the wrong place and you achieve this somewhat different. I do get it's something which is far away from a necessity and it's use probably is debateable, but it sounded like something that I would definitely expect to play around with in LWJGL.

Search results gave me nothing to clear it up.

[Fool Running]

Which graphics card are you using? I recall that NVidia (maybe ATI as well) drivers default to rendering 3 frames ahead (which means that you have a minimum of 3 frames between the mouse moves and it shows on screen). The difference in "latency" might just be the fact that with VSync on your max framerate is 60 (assuming that is your refresh rate). With VSync off, you could be getting much more (like 200 fps), although I don't know how you coded your app. This means that you might have a 50ms vs 15ms delay (3 frames at 60fps vs 200fps).
You can check this by looking at your driver settings and making sure the frames-to-render-ahead setting is set at zero.

This setting has killed me far too often in shooters where the actions I see actually happened 3 or more frames ago.

[HerrKhosse]

Thanks for the reply!
I actually am currently using an older NVIDIA, altough I used an ATI some months ago where I had the same problem with VSYNC.
I just discovered the "render-frames-ahead" option in the NVIDIA Control Panel (I don't think there's an option in the ATI Catalyst Cotnrol Center), anway, I've set it to zero and still: no change in latency.

In the Description of the NVIDIA Control Panel, it actually says: "This feature only works for games using DirectX"

I think I've read your theory in an older post from another guy and I can verify that this is not the case in my scenario.
If I "glue" my max fps to 60 with Display.sync(60) and set VSync to false, there is NO recognizable latency, when I set Vsync to true, it's very noticeable. (This is nothing I experience only in LWJGL, in every game where is VSync, I notice the latency when there are smooth changes)

Currently I'm not doing anything fancy, normal rendering routine:

setVSync(true/false);
Repeat:
<Clear & Render>
Display.update();
Display.sync(60);

I guess one explanation for the latency would be that it's due the time the Display sets up the picture while the renderer halts?
Something like (with the imaginary bucket visualization ):

(synced)
- Fill "Bucket" with pixels
- Hand it to the Display, Display is currently not busy so it takes the bucket and begins displaying
- Immiedeatly fill the next bucket
- Offer it to the Display, the Display currently is still busy ordering the little men drawing pixels on screen, so the engine freezes and does not draw any newer frame until the display took his bucket

That could obviously be absolutely wrong, I'm just trying to get some ideas on this
I guess there would be no problem by just emptying the bucket and fill it with newer frames all the time instead of keeping the first frame done.