[GEM-dev] pix_filmDarwin...
IOhannes m zmoelnig
zmoelnig at iem.at
Fri Dec 8 13:32:26 CET 2006
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
More information about the GEM-dev
mailing list