[GEM-dev] Compiling Vertex Array stuff under OSX
IOhannes m zmoelnig
zmoelnig at iem.at
Tue Oct 19 20:15:34 CEST 2004
B. Bogart wrote:
> Prehaps the pix_film object could print out a message when trying to
> load a rgb codec in yuv space?
well, this is a bit complicated.
there is no such thing as a "yuv space" into which an "rgb"-object (e.g.
movie) is loaded.
the idea is that a pix-source supplies the image in a "native" way.
you should be able to override this "native" way with a "colourspace"
(or "colorspace" if you prefer...) message.
all modifying objects should have methods for all colorspaces (if this
is possible); if such the needed method has not been implemented (yet),
an error-message is sent to the console.
> Any plans for automatic colourspace switching?
this has been discussed once; chris has argumented (and by now i agree)
that automatic switching would be a sincere performance penalty: the
problem is, that the system will choose to convert for you and you will
not know why it get's sooo slow; if you have to do the conversion
"manually" then you might optimize it easier
(but we could do automatic conversion + output to the console that
conversion is done! this would tell the user what is going on (so slow)
and it still would work)
pix-sinks (like [pix_texture]) should handle all colour-spaces.
since windos and linux don't know yuv-textures (at least i wasn't able
to convince them to display correctly) they are automatically converted
on these platforms.
on OSX, yuv-textures should theoretically be possible, however there are
bugs in (older releases of) the drivers (for nvidia).
i don't know any failsave method to detect such bugs (except for looking
at the green image, of course) and solve them on the application side
(btw, i don't think that solving driver's bugs is a task for an application)
mfg.as.dr
IOhannes
More information about the GEM-dev
mailing list