[PD-dev] [GEM] evenMORE HOT cvs action!
zmoelnig at iem.at
zmoelnig at iem.at
Fri Apr 11 22:55:09 CEST 2003
i think daniel has answered most questions.
Zitiere chris clepper <cclepper at artic.edu>:
> >Zitiere Me <tigital at mac.com>:
> >
> >> pix_filmDarwin
> >> - like chris mentioned, this has been improved in the same manner
> as
> >> pix_filmDarwinYUV, meaning much improved frame access and speed...
> >
> >great.
> >anyhow, i'd like to move all the OS/lib-dependent film-stuff into
> >film*.cpp files.
> >any objections?
>
> can you explain exactly how the new filmDarwin would be different
> than pix_filmDarwin? i think i see the usefulness for linux and the
> many libs required to play various types of files, but the OSX stuff
> looks exactly the same. maybe we could use ffmpeg for OSX too, but
> overall the platform dependencies are still there just under
> different names.
what you mean by "OS-X stuff looks exactly the same" ?
i just copied and pasted the code from pix_filmDarwin into filmDarwin.
the idea was to se-arate the platform/library dependent code from the actual
[object] code.
I have to admit that the old way is really quite nasty, especially with
[pix_movie] inheriting from os-specific classes (yes, i know, that i have
introduced this)
of course the code would not change much, it is just about defining a
(hopefully) clean API that is used for accessing video-data from within Gem (or
even other libraries, but i have put the pixBlock-struct into the film* classes
for easiness)
> pix_film already has the alias, but pix_video doesn't at the moment.
and with a platform-independent film* (or video*) class, there would be no need
for making aliases (which is really nasty)
> also, there is pix_filmYUV and yuv_videoDarwin because GL doesn't
> like switching color-spaces for textures. so right now the render
> chain has to be initialized as YUV or RGB and kept that way or the
> textures will get corrupted.
i haven't experienced this (problems with colourspace-switching) but this might
be a problem only for switching between very different spaces, like RGB and yUv.
RGBA/RGB/BGR/BGRA-switching normally works fine.
basically i have thought of specifying the format at load time (is this too
late?) of film-data.
what about trying to fix the problem in [pix_texture] ? are there any
possibilities for this ?
will there be a fix for the problem at the macOS side sometime ? (it seems to be
a problem with the macOS specific extension of openGL rather than with "normal"
openGL)
mfg.as.r
IOhannes
More information about the Pd-dev
mailing list