LÖVE

I've got an occasional one second long stutter, and I've ginned up my love.run to see what the source could be. I've narrowed it down to love.graphics.present() taking about a second a few times a minute. I'm a little baffled by this as the draw and update calls return very quickly. It does seem to be somewhat specific to one machine with a radeon 5770, as my dev machine had no such issues.

What's happening in love.graphics.present()? I checked out the docs here: http://love2d.org/wiki/love.graphics.present but I didn't get much insight into what could possibly go slow there.

Sorry if this isn't the right place to ask this, and thanks for any suggestions.

cheesehound wrote: What's happening in love.graphics.present()?

When one calls love.graphics.present(), a C++ function is called inside Love2D. This is that function, verbatim:
As you can see, the function is very short. Love2D is basically a beautifully designed package which glues a lot of pre-existing libraries together. In regards to your question, the library of interest is SDL. SDL handles window management and the OpenGL context.

Here, SDL is telling OpenGL, "we're done drawing. Feel free to update the user's display with the image that is in the current buffer,

Why is it taking so long?

I don't know. Time it. Try to work the run loop into only calling present() once every 1.0/60 seconds. ( that works out to about one call to present() every 16 milliseconds).

Just a shot in the dark, but might that be because it handles vsync, slowing down the process that way?

Your driver could also be queuing the changes and then only sending them on present, there's a lot of weird stuff drivers can do to cause this.

What OS are you using?

Hmm, periodic stuttering slowdowns in a realtime app written in a garbage-collected language... what could it beeee? ;D

Whenever a native function call completes in Lua, the GC is optionally run. What's probably happening is that you're allocating objects with abandon, creating tons of garbage for the GC to clean up. Of course while the GC is running, you can't do anything else.

Try printing out the memory usage with collectgarbage("count"). I'll bet you five bucks the memory usage will increase over time, and then you'll get a stutter, and then it'll drop. Rinse, repeat.

I'm trying to figure out what the stuttering in the demos for love on windows is all about, and came across this post. This isn't the answer to MY question, since the symptoms presented here do not really match up to a GC problem. What this is, is an SDL problem. What happens when you call SDL swap buffers on a system whose video card does not support double buffering? A huge pause as a manual memory copy of the whole video buffer takes place. What you're supposed to do in this situation is write a branch/version of your game drawing code that uses dirty rects instead of buffer swapping for most efficient video performance. I do not know if love provides that level of low level control though.

Here is what the documentation for SDL_GL_SwapBuffers(); says

http://sdl.beuc.net/sdl.wiki/SDL_GL_SwapBuffers


"Swap the OpenGL buffers, if double-buffering is supported. "

what if double-buffering is not supported by your particular video card, and you attempt to call this function? That is not clear for this particular method, but with the 2D SDL_FLIP method, what SDL will do is do a byte for byte copy of your entire frame buffer, which kind of takes a while.

Which video cards or drivers don't support double buffering? I think OpenGL 1.3 or 1.4 is the absolute minimum that LÖVE supports, so if double buffering is only not supported on cards that don't support OGL 1.3/1.4 then it's pointless to provide support.

Now I can't be 100% sure that this is /really truly/ the problem. I seem to remember though that "double buffering" is an option settable in some driver control panels for open GL, and some googling shows some posts indicating something like "I disabled double buffering and performance improved on game X!". I also know that double buffering was not supported on an EEEPC701 I tried out eons ago, probably as a consequence of limited video memory- so these machines exist here and there.

edit:
reading a bit more, this may all just be a red herring. A call to glSwapBuffers will likely bock until the next vsync if vsync is turned on, inflating its measured "profile" time. You need to disable vsync to find out how long it's actually taking.