Well shit, you had me concerned for a minute.&nbsp; <br><br>Here&#39;s the full story:<br><br>The fast path for texturing involves asynchronously uploading the texture from CPU memory to the GPU.&nbsp; pix_movie does this without caching the image (which involves copying it) and instead calls the texture instructions for the previous decoded frame.&nbsp; The code looks like this:<br>
<br>render {<br><br>texFrame()<br>getFrame()<br><br>}<br><br>It worked great from 10.2 to 10.4, but for some reason it is broken completely on 10.5 and the 10.4 Nvidia drivers.&nbsp; Why?&nbsp; I don&#39;t know but the code behind the async upload is Carbon which is dead and buried at Apple.&nbsp; No fixes planned, you need to move to Cocoa.&nbsp; Nice.<br>
<br>What pix_separator is going to do is hold a copy of the frame in memory that is not related to the Quicktime decode and the driver can yank that up to the GPU whenever it feels like.&nbsp; This is not optimal but it is the option currently available.&nbsp; I have done a little work on some CoreVideo code which only works on 10.5.&nbsp; Don&#39;t hold your breath for this code being as fast as 10.4 since CoreVideo does a lot of memory copying too.<br>
<br>Good luck.<br><br><div class="gmail_quote">On Mon, Apr 14, 2008 at 4:12 PM, marius schebella &lt;<a href="mailto:marius.schebella@gmail.com">marius.schebella@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
sorry for the confusion. I wanted to say pix_movie, but said pix_film...<br>
<br>
just to make this clear: pix_film with separator is working fine (as I wrote before). I did not experience any performance drawback with the one separator. but I will try to use it with client_storage 1.<br>
the second file I sent was the bug of pix_*movie* into pix_record.<br>
marius.<br>
<br><br></blockquote></div><br>