[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