Heiko's picture

GameWindow.SwapBuffers() sometimes takes over a second to execute

I encounter a very strange problem. Maybe someone can point me in the right direction.

When I work on my application for a few hours, at some point, GameWindow.SwapBuffers() suddenly becomes extremely slow (it takes about a second). Sometimes restarting the application helps. When I restart the computer the problem goes away for a few hours.

It might happen because I quit and restart the application a lot during development. Perhaps a problem with improper cleanup, but I didn't find anything that could cause a problem so far. I create all my textures on startup and rely on GameWindow.Dispose() to clean them up.

Is there anything I can do or test to find out what might be the root of the problem?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Video card / drivers / OS?

Check your memory usage. You could be seeing the results of a leak in video memory, which are often hard to detect. (Modern operating systems virtualize video memory just like system memory, so you won't get an outright failure once you run out of memory).

If you are using MakeCurrent(), be advised that some older drivers have been known to leak memory on that call.

GameWindow.Dispose() call GraphicsContext.Dispose() which in turn calls [wgl/glX/agl/egl]DestroyContext() which is supposed to clean all OpenGL resources (i.e. OpenTK doesn't do any housekeeping itself, it leaves everything to the driver). I don't think this is a cleanup problem.

Heiko's picture

Thanks for your fast and thorough answer!
Is there a way to check the video memory usage (programmatically or with a tool) to find out which function call might cause the potential memory leak?

the Fiddler's picture

Try running one of the OpenGL debugging tools available, like: gDEBugger (the best), BuGLe or glslDevil. I think the first one can also track memory usage.

Xeethrax's picture

So I've been having this problem lately as well. The problem arose rather suddenly..

My OpenTK games are rather simple 2D, but with alot of (big) sprites/animations and alot happening at the same time. I haven't had any problems before now, and some of the games are soon to be 2 years old..

At first I thought it might be some blooper I've made in my code, but as long as it doesn't interfere with the pipeline processing, I can't imagine it having any effect on the duration of SwapBuffer()..?

I've been trying to figure if I'm hitting some walls around the amount of textures / size of textures, and while reducing the amount of draw operations per frame does reduce the amount of spikes, it doesn't eliminate them. I've also realised that I wasn't making all my textures the proper size (width and height divisible by 4), and thus GL_COMPRESSED_RGBA wasn't working for all textures. Fixing some of the biggest textures did also seem to reduce the problem.

The problem seems to (mostly) occur when VSync is on, and disappear when i turn VSync off. See screenshots.. (Rightclick->Show image to see the whole image).

Vsync on:

VSync on

Vsync off:

VSync off

I'm using latest build of OpenTK, but I've tried reverting to older versions as well .. with no luck. I've been debugging this for 5 days now, and if I've made a mistake that causes SwapBuffer() to lag for some reason, I've still yet to find it :/ The fact that it all seemed to happen so suddenly makes me think that it was one single mistake I made rather than stepping over any limits, especially considering that I have to remove alot more drawing operations than was added since the problem arose, to remove the stutters / lags.

Any thoughts?

Edit: Oh and also, I might mention that FrameEventArgs's Time property is inaccurate, I'm forced to use Stopwatch until it gets.. better :) And the GameWindow.UpdateFrequency is unaffected by .TargetUpdateFrequency (lies at about 10000-50000 in my games), though update is only called at the proper times. Not exactly showstoppers, but I thought I'd mention it.

Xeethrax's picture

Right, so.. I updated my graphics driver and the problem disappeared. Not entirely sure about what to make of that, since the problem appeared a while after my previous update. Oh well, just happy it's gone (for now) ;)