[GEM-dev] pix_filmDarwin...

[chris clepper]

The reason the two Darwin files exist has to do with the 'auto' mode
playback.  On the Mac the most efficient way to play Quicktime clips is to
have Quicktime do the tasking internally.   So rather than 'auto'
incrementing the frame counter every render call, these objects ask
Quicktime where the movie is currrently and update the frame counter.  This
is opposite of how the other formats work.

Also, movieDarwin has a reverse order of texturing then decompressing a
frame which makes the async DMA uploads work better.

A more unified code set would probably be better in the long run to
maintain, but I haven't figured out a way to reconcile the two without a
number of #ifdefs which is not that great a solution.

On 12/7/06, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
>
> hi.
>
> i try to move the threads from pd-list to here, as it is more
> appropriate (and my thread-view makes it almost impossible to see the
> subject lines due to the depth ;-))
>
>
> i see that chris has submitted a hack to disable the
> pix_filmNEW/pix_movieNEW stuff.
>
> i am fine with that for now, since pd-extended wants to be released
> soon, but on the long run i would rather have this reverted and have a
> look at why it failed to use pix_filmDarwin in the first place.
>
> while disabling the entire code is a quick fix, i guess it will not
> really help us on the long run to unify these objects.
>
> what i am also talking about for ages is to rename pix_film.cpp to
> pix_filmOS.cpp and pix_filmNEW.cpp to pix_film.cpp
> this should make the renaming-schemes less complicated (only 2 classes
> that will try to reserve the name [pix_film] instead of 3).
> probably we could also not use pix_film.cpp as a new name for
> pix_filmNEW.cpp (but i lack of good ideas; "NEW" should at least vanish
> and make place for something that tells us more about the functionality
> than the date...)
>
> of course this also applies to pix_movie.
>
> any objections to this?
>
>
>
> and i would very much like to ask to speed gurus among us, whether it
> would be possible to use the pix_film(NEW) with optimized paths, in
> order to make pix_filmDarwin,... really superfluous and deprecate it on
> the long run.
>
> fmga.sdr
> IOhannes
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20061207/42c3e0b5/attachment.htm>