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.
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@iem.at
http://lists.puredata.info/listinfo/gem-dev