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

[Ian M. <ia...@ge...>]

On Sat, Jun 15, 2013 at 11:23 PM, Nathaniel Virgo
<nat...@gm...>wrote:

> 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.
>
VSync is enabled by default in Windows as well in PyGame. When writing a
windowing backend, it's something that the OpenGL context must disable.


> 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.
>
In my limited experience with GLUT, VSync is always disabled on any
platform.

The situation is more complicated than you describe. In particular,
disabling VSync can lead to much higher framerates if you're limited below
the screen's refresh rate, and framerates higher than 60Hz *do* lead to
better quality if triple buffering is available. VSync is enabled for
applications that demand no tearing and disabled everywhere else for
maximum performance. It does complicate timing, so I typically clamp to
60Hz and enable VSync.


> 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.
>
I agree. GLUT is useless. That's not PyOpenGL's fault, though--the C
version of GLUT that PyOpenGL wraps is useless. Since GLUT does not provide
a portable way to toggle VSync, neither does PyOpenGL's wrapper. Perhaps
something could be added to help. Really though, the best solution is to
just leave GLUT. The only place I ever see it used is in toy examples.


> Best regards,
> Nathaniel
>
Ian