Well shit, you had me concerned for a minute.
Here's the full story:
The fast path for texturing involves asynchronously uploading the texture from CPU memory to the GPU. pix_movie does this without caching the image (which involves copying it) and instead calls the texture instructions for the previous decoded frame. The code looks like this:
render {
texFrame() getFrame()
}
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. Why? I don't know but the code behind the async upload is Carbon which is dead and buried at Apple. No fixes planned, you need to move to Cocoa. Nice.
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. This is not optimal but it is the option currently available. I have done a little work on some CoreVideo code which only works on 10.5. Don't hold your breath for this code being as fast as 10.4 since CoreVideo does a lot of memory copying too.
Good luck.
On Mon, Apr 14, 2008 at 4:12 PM, marius schebella < marius.schebella@gmail.com> wrote:
sorry for the confusion. I wanted to say pix_movie, but said pix_film...
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. the second file I sent was the bug of pix_*movie* into pix_record. marius.