On Wed, Feb 29, 2012 at 4:52 AM, Cyrille Henry <span dir="ltr"><<a href="mailto:ch@chnry.net">ch@chnry.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Le 29/02/2012 09:34, IOhannes m zmoelnig a écrit :<br>
<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
and both [pix_texture] and [pix_snap] allow for asynchronous<br>
DMA-transfers already (though i only added PBO-tarnsfers to [pix_snap] a<br>
week ago or so).<br>
it's not really documented anywhere (yet), but you can send a [pbo $1(<br>
message to both these objects to specify the number of PBOs to use (with<br>
"0" being the default behaviour)<br>
</blockquote>
<br>
Do you mean that since last week pix_snap should be lot's faster than it use to be?<br>
<br></blockquote><div><br>Years ago I spent some time with Apple, ATI and Nvidia trying to get the best pix_snap performance, but readback from the main backbuffer will always wait for all drawing to end and then transfer. There is no way not to call glFlush/glFinish either explicitly or implicitly on the main buffer to finish drawing. If you have some more drawing to do there might be an increase in performance, but for capturing an entire rendered image at the end of the drawing calls there is ultimately not much optimization possible. <br>
</div></div>