[GEM-dev] Problem with glitching on OS X at high frame rates

chris clepper cgclepper at gmail.com
Tue Jul 17 23:46:47 CEST 2012

On Tue, Jul 17, 2012 at 5:09 PM, Jack <jack at rybn.org> wrote:

> If you have Gem at 100 fps and you screen at 60 fps, you should
> encounter a problem of sync at a certain moment, no ? If not, can you
> explain more ?
> Maybe the best is when you have Gem fps as a multiple of your screen fps ?
> Thanx for the rest of explanation.
> ++
The GPU has at least two buffers for drawing to screen.  The back buffer is
where all of the rendering is done and the front (or display) buffer just
gets a copy of the back buffer at a specified interval.  The idea is that
rendering can take a long time while a copy cant be done quickly (GPU VRAM
copies are insanely fast now), so you can take almost all of the render
time to draw the frame then swap buffers at the last instant and then go
back to rendering.

I initially set the OSX version of GEM to VBL sync to remove the 'tearing'
artifacts that horribly plagued other software (Nato advertised it as a
feature).  I wanted smooth HD video regardless of GEM render rate and used
VBL sync and async texturing to do it (this also ended up in the VLC GL
rendering code on OSX that I advised on a long time ago).

Using VBL sync will only flip the back buffer to the front at 60 fps.  It
should be possible to feed GL and the GPU more data than the 60 FPS you
need but it might not be displayed.  Or maybe the results will be
indeterminate?  It could be back to the tearing issue if the back buffer is
partially filled at swap time.

I used to know all of the guys who wrote the Mac drivers and made the ATI
chips, but we have all gone on to other things, so I can't get a definitive
answer right now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20120717/05185183/attachment-0001.htm>

More information about the GEM-dev mailing list