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
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@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@iem.at http://lists.puredata.info/listinfo/gem-dev
hi.
chris clepper wrote:
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.
well, i guess after some careful considerations, we could find a way to handle this with the "auto" stuff. (e.g. by moving the auto-incrementing code into the film* classes (or into the film class and overwrite it for filmDarwin)). can Quicktime's tasking also be used to have variable playback speed (i guess so; but before reading the code i'd rather ask)
Also, movieDarwin has a reverse order of texturing then decompressing a frame which makes the async DMA uploads work better.
oh i see, there is definitely some magic involved here ;-) hard to solve this generically.
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.
depends. if it turns out to be a pix_texture-lie preprocessor torture, then i totally agree.
mfg.adr IOhannes
-
chris clepper -
IOhannes m zmoelnig