al_flip_display takes 30ms occasionally
kovarex

I'm trying to solve this subtle bug for some time now. The problem is, that there are slight lags/stutters during the gameplay. I found out that the al_flip_display method itself (which should be quite quick I guess) is taking 2-3 ms when the vsync is disabled, which is problematic, but the main problem is, that when the vsync is turned on (which is practically mandatory), the function runs for more than the 16.666ms on 60Hz monitor.

Also I found out, that when I disable one of my monitors, it happens much less frequently.

Any hints?

Chris Katko

I might have run into this myself. I'm not sure.

What operating system?

What graphics driver (OpenGL/DirectX/etc)?

What version of A5, are you using the up-to-date WIP?

[edit] Also, try running a profiler to catch the function calls inside and see what ones INSIDE al_flip_display() are taking up time.

And/or, could you try to build an a smallest-possible example which still exhibits the problem?

SiegeLord

It is useful to know the platform, and how exactly you're using vsync. One note, however, is that al_flip_display can take as long as it needs to, as many drawing operations are deferred until that happens (this is done on OpenGL/D3D's side of things).

kovarex

I test it on win 7 64 bit, but I can also try to reproduce it on OSX/Linux as well as I have these here.

On Win I use the default d3d, the 5.1.8 allegro with few custom modifications that shouldn't have effect on this.

Edit: Well, In the first post, I specified that without vsync, the flip took 2ms top, so the top time for the whole operation should be 2ms + 16ms waiting for vsync, but not 30.

It almost looks, like the internals wait for the vsync twice, I will try to do some measurements inside the flip internals to find out where it happens.

SiegeLord
kovarex said:

It almost looks, like the internals wait for the vsync twice, I will try to do some measurements inside the flip internals to find out where it happens.

That's very possible! Oh yeah, just to make sure... you are not using al_wait_for_vsync are you? Because using that function will indeed have a very real chance of waiting for vsync twice.

beoran

Why does that even happen? Sounds like al_wait_for_vsync is broken in some cases?

kovarex

No, I'm not using al_wait_for_vsync manually.

I did experiment with calling it manually while the flip vsync was disabled, but it didn't really work (there was the monitor tearing). This makes sanse, as the 2ms to solve the flip logic was long enough to get off the vsync spot.

SiegeLord
beoran said:

Why does that even happen? Sounds like al_wait_for_vsync is broken in some cases?

The documentation explains it pretty well, I think. The real question is why you'd even call it as opposed to using the display option (the reason is that the display option sometimes doesn't work... but I forget why).

Thread #615015. Printed from Allegro.cc