[GEM-dev] pix_freeframe and m_instance

[james tittle]

curious...

On Feb 8, 2006, at 1:59 PM, james tittle wrote:
> ...aha, a coupla well placed breakpoints later, and it seems that  
> there's an osx problem with the format assignments at the start of  
> processImage():  fr'instance, I loaded a movie with [colorspace  
> RGBA<, but the m_image.format that gets passed to "format" is  
> GL_YUV422_GEM!  Obviously this isn't right, so i'll have to track  
> down why...

...I think I've found a subtle bug in our imageStruct conversions in  
GemPixUtil.cpp :-(  Looking at imageStruct::setCsizeByFormat(),  
there's a horrible, confusing amount of #ifdef's to accommodate the  
fact that apple's native gem colorspace is YUV, but everybody else is  
RGBA...within these #ifdef's, there are "default:" cases for the  
switch(format){}, such that in the __APPLE__ platform, we never get  
to "case GL_RGBA:", because "case GL_YUV422_GEM:" is tested first,  
and on __APPLE__ is the "default", so it goes no further!  I've  
removed this, but it still doesn't work, because now there's no a  
problem where we test for GL_BGRA_EXT instead of GL_RGBA on  
__APPLE__, so it just goes to default YUV again!

...so, I'm not sure what to do:  sure, I could go ahead and also add  
GL_RGBA to the __APPLE__ test for GL_BGRA_EXT (also needing to do  
this for GL_RGB/GL_BGR...), but then I think we'll be in a situation  
where all processing inside of the freeframe plugins will be done on  
incorrect color channels :-\

...anyone see a way outta this?

jamie

ps:  I'm also wondering if all of this backwards GL_* stuff will have  
to be changed for the intel macs...!