On Tue, Jul 17, 2012 at 5:09 PM, Jack <span dir="ltr"><<a href="mailto:jack@rybn.org" target="_blank">jack@rybn.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
If you have Gem at 100 fps and you screen at 60 fps, you should<br>
encounter a problem of sync at a certain moment, no ? If not, can you<br>
explain more ?<br>
Maybe the best is when you have Gem fps as a multiple of your screen fps ?<br>
Thanx for the rest of explanation.<br>
++<br><br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div></div>