[PD] [GEM-dev] shall we release?

chris clepper cgclepper at gmail.com
Mon Apr 14 23:27:34 CEST 2008

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 {



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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080414/acc18261/attachment.htm>

More information about the Pd-list mailing list