[SOLVED] window.pollEvent() lagging when Joystick not plugged in

[Nexus]

How did you switch between OpenGL versions? Different context settings in the application, with the same driver? In any case, this problem doesn't seem to be related to SFML...

And I don't know why you keep saying "vblank sync", it's "VSync" which means "vertical synchronization".

[mkalex777]

How did you switch between OpenGL versions? Different context settings in the application, with the same driver? In any case, this problem doesn't seem to be related to SFML...

And I don't know why you keep saying "vblank sync", it's "VSync" which means "vertical synchronization".

I'm checked it in virtual machine which uses OpenGL 2.1.
By the way, it seems that vblank sync has it's own specific in OpenGL.
Here is some info:
http://stackoverflow.com/questions/589064/how-to-enable-vertical-sync-in-opengl
https://www.opengl.org/wiki/Swap_Interval

So, it seems that vblank sync depends on OpenGL implementation.
I'm not sure how it's cross platform support is implemented in SFML.
Does SFML support vblank sync at all on Linux?

[mkalex777]

And I don't know why you keep saying "vblank sync", it's "VSync" which means "vertical synchronization".

Because it's name taken from low level implementation. "vblank" means vertical blank - it's the flag from the videocard which means that the vertical blank signal is currently active. When this flag is active, it's the time after end scanning of previous frame and before begin scanning of the next frame. So, it's the time to change video memory with no tearing effect.
Actually vertical synchronization means waiting for vblank flag=1 (active).

vblank sync is just more clear term which describes what happens exactly - synchronizing with vblank flag from the videocard.

[espectra]

May be it's related with OpenGL version, here is my observations:

OpenGL 4.5: vblank sync works OK
OpenGL 2.1: vblank sync didn't works

It's quite strange - the OpenGL driver on my PC only supports 2.1, but apparently for Windows, OpenGL uses a Windows-specific extension to set vsync: the wglSwapIntervalEXT extension. My driver DOES support that and indeed SFML gets the extension and uses it, by setting the swap interval to 1 when setVerticalSyncEnabled() is set to true.

I'm not yet sure if it's actually enabling vsync and preventing tearing, but it definitely seems to NOT be limiting the frame rate to the refresh rate of 60Hz. Same problem with LWJGL, so I doubt it's simply an SFML problem.

I don't know what's going on and googling info is pretty frustrating and not turning up anything useful.

[mkalex777]

Here is some more details: http://www.d-silence.com/feature.php?id=255

"There is no Vsync in OpenGL as a command. Most apps use the GLFlush command, sometimes followed by a GLFinish command. The GLFlush command basically says "Ok, what ever commands you have in your buffer, send 'em to the rendering device now, and get it working." It doesn't care where the raster is in the drawing sync, it just goes out and does it. The GLFinish command will then make the app wait until the rendering device has completed all the commands it has been sent up til then. This gives you the fastest feedback, fairly obviously. Now, depending on whether you are double buffering your video displays (ie rendering to the back one while the front one is being displayed) you might want to use a swapbuffers command. This means that you can afford to slap out commands to the rendering device when ever you feel like it, since it's always going to be rendering to an unseen buffer. The SwapBuffers command does what it says, it swaps the buffers between the front and the back. When it actually does this, ie at Vsync or just randomly whenever it can depends on the card you are using. Sometimes you can set the 'wait for Vsync' in the properties dialog for your card, sometimes it has to be set via registry options. It's messy and highly card dependant. Obviously working in a window you don't get any kind of Vsyncing going on."

So, it seems like OpenGL issue, there is no direct way to control vblank sync in OpenGL. It depends on driver implementation...

If you need it, you can use Direct3D for vblank sync and sfml/opengl for rendering. But it's really ugly solution which mixes Direct3D and OpenGL

When you use SetVerticalSync in SFML it actually uses first available function from the following list:
- glXSwapIntervalEXT
- glXSwapIntervalMESA
- glXSwapIntervalSGI

If all these functions is not available it just make warning and ignore it.

Probably it will be better to rename SetVerticalSync to SetSwapInterval to avoid confusing. There is no way to control vblank sync with OpenGL.

[espectra]

Probably it will be better to rename SetVerticalSync to SetSwapInterval to avoid confusing. There is no way to control vblank sync with OpenGL.

But you tested it on OpenGL 4.1 and reported that it worked, didn't you?

May be it's related with OpenGL version, here is my observations:

OpenGL 4.5: vblank sync works OK
OpenGL 2.1: vblank sync didn't works

This whole thing with vsync & OpenGL is very confusing. 

[Jesper Juhl]

So, it seems like OpenGL issue, there is no direct way to control vblank sync in OpenGL. It depends on driver implementation...

If you need it, you can use Direct3D for vblank sync and sfml/opengl for rendering. But it's really ugly solution which mixes Direct3D and OpenGL

Asking for "vsync" is a request to the driver. There is no guarantee it will (or can) be honored.
You need to ensure that a) your logic updates are decoupled from your rendering. b) your rendering is independent of your framerate. c) realize that you can't get "vsync" everywhere (does it even make sense for modern lcd panels rhat don't actually have a vertical retrace like old CRT monitors?).
Vsync makes sense if you have a tearing problem. Don't think of it as a "fix framerate limit" thing. If you need to fix (somewhat) your framerate, you need to implement sleeps that make you render at roughly the framerate you want (and handle the inacuracies). Don't rely on vsync for that.

[espectra]

Asking for "vsync" is a request to the driver. There is no guarantee it will (or can) be honored.
You need to ensure that a) your logic updates are decoupled from your rendering. b) your rendering is independent of your framerate. c) realize that you can't get "vsync" everywhere (does it even make sense for modern lcd panels rhat don't actually have a vertical retrace like old CRT monitors?).
Vsync makes sense if you have a tearing problem. Don't think of it as a "fix framerate limit" thing. If you need to fix (somewhat) your framerate, you need to implement sleeps that make you render at roughly the framerate you want (and handle the inacuracies). Don't rely on vsync for that.

This is good info! Thanks.

About the "modern lcd" not having vsync, that's an interesting topic. Aren't most displays actually LED displays these days?

Anyway, regardless of whether vsync works on my notebook's built-in display, I've never really seen tearing on it.

However, when testing on a friend's desktop PC with external LED display, I've seen some obvious tearing happening with the same test program.

Since I kind of enjoy understanding the technical stuff like this, I'd like to learn what's going on between testing the program on my notebook and on a desktop. For instance, the Intel media control panel on my notebook has a Vertical Sync option which can be set to "Application Settings" or "On". I don't know if that applies to DirectX only or also OpenGL, since it basically hides some of that underlying detail from the user (older versions of the Intel Graphics drivers seemed to show OpenGL settings explicitly...)

I wonder if we could come up with a simple test case that includes the features you mentioned (decoupled logic and rendering, framerate independent rendering) to show how the setting of vsync (wglSwapIntervalEXT) affects everything?

[mkalex777]

But you tested it on OpenGL 4.1 and reported that it worked, didn't you?

it works because driver doing it with glXSwapIntervalEXT(1), but if you call it it doesn't means that you will have vblank sync, it depends on driver desire.

[mkalex777]

Asking for "vsync" is a request to the driver. There is no guarantee it will (or can) be honored.

There is no way to ask OpenGL driver for vblank sync. When you call SetVerticalSync(true) it actually enable SwapInterval. Vblank may be used with SwapInterval and may not be used. It not depends on support vblank sync in videocard driver. It depends on OpenGL driver.

[mkalex777]

Vsync makes sense if you have a tearing problem. Don't think of it as a "fix framerate limit" thing.

No. Vsync allows to get equal render intervals with minimum delay between render frame and swap frame. In that way it improves smoothness of movements.
Actually you can eliminate tearing effect with using buffered rendering, but if you want to make smooth movements with equals intervals it will be too hard without vblank sync.
SFML SetVerticalSync eliminates tearing effect, but it actually doesn't deal with vblank sync.

[mkalex777]

does it even make sense for modern lcd panels rhat don't actually have a vertical retrace like old CRT monitors?

Yes, it has real sense for all modern LCD with no exception, because all they receive video signal in the same way as it works with CRT. They may use digital signals instead of analog and short vblank but it still exists 

[zsbzsb]

...You don't need 4 posts in the matter of 15 minutes. You can post multiple replies in a single post.

[mkalex777]

...You don't need 4 posts in the matter of 15 minutes. You can post multiple replies in a single post.

Sorry, other forums automatically merge posts with short interval, so I get used to it