Re: [PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

[Nathaniel V. <nat...@gm...>]

On 15 June 2013 16:13, Ian Mallett <ia...@ge...> 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

-- 
Nathaniel Virgo
http://nathanielvirgo.com