On 15 June 2013 16:13, Ian Mallett <ian@geometrian.com> wrote:

I meant, that link has some of the information to get you started. Getting started with double-buffering instead of tweaking VSync is probably the solution to most problems. Because of the way displays work, a completely rendered graphics frame is much more important than synchronizing display blit to the actual rendering.

Many windowing systems automatically enable VSync initially. SDL (PyGame in Python) is one example. GLUT is not one, as I remember. Ultimately any solution is platform specific--though it may be masked in a platform independent layer. GLUT apparently doesn't provide such a platform independent layer for you, so any solution is going to be platform specific.

But that's already been established. GLUT has other problems. Its callback methods are crude and inflexible. Its support for context creation is lacking. It's built on ancient technology and is semi-proprietary. It supports only one window and has a restricted set of controller inputs and, as you see, poor platform abstraction for some tasks.

I don't know what's wrong with your ctypes code, but I can tell you that there are much better options than GLUT. PyGame, which I mentioned earlier is an excellent choice. It is better than or equal to GLUT in literally every way, including VSync support--which you can toggle when creating a window. I know it's not really what you asked for, but it's my recommendation.

Thank you for the pygame recommendation. I had looked into it already, but when searching for things like "pygame opengl vsync" all I saw was questions about how to turn vsync on, but no answers besides the code I already posted, which crashes. However, after your mail I played around with some example code, and it seems that vertical sync is enabled in pygame whenever you enable double buffering. I don't know whether this behaviour is cross-platform or not, but I'm only likely to run this code on my Mac in the near future, so I'm only slightly worried by this and will probably use this solution.

Note that vertical sync and double buffering are separate issues. I'm using double buffering, of course. However, when using PyOpenGL/GLUT on OS X it doesn't wait for the vertical refresh before swapping the buffers. The result of this is tearing and inconsistent timing, and for what I'm doing these are things I absolutely need to avoid. I think most other people will also need to avoid these things in most other situations as well. IMHO, the only time you wouldn't want to wait for the vertical refresh is when profiling, so that you can accurately measure how many frames per second can be rendered. In just about any kind of production code there's no point in rendering faster than the display can handle, and it's much more important to have consistent timing and to avoid tearing.

I had already worked around the issue by using pyglet to manage the windows. However, I don't like this solution because nobody seems to be developing it anymore and there's no official release that works on OS X Mountain Lion. I installed from the latest source, which does work, but I don't hold out much hope that it will continue to work after future OS upgrades - so now I will probably switch to pygame instead.

I'm not a huge fan of GLUT either, but if you're going to go to the bother of wrapping it, it seems weird not to also provide a method for toggling VSync. Especially since (as far as I can gather) VSync is enabled on Windows/PyOpenGL/GLUT but disabled on Mac/PyOpenGL/GLUT, which basically guarantees that anyone who does develop using it will have unresolvable differences in behaviour between platforms. All I'm suggesting is that there should be a special OpenGL.platform.enableVerticalSync() function that wraps the platform-specific stuff for this task. Without it, the PyOpenGL wrapping of GLUT is quite limited in its usefulness in my opinion.

Best regards,

Nathaniel Virgo