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...!