Ivan suggested that this be forwarded to the list as it would help clear up some possible confusion about GEM, OSX, RGB vs YUV, etc:
At 7:00 PM +0000 2/24/03, Ivan Franco wrote:
I'm talking about the basic help files for performance comparison. I'm running a Ti 500 Rev.A (same cheap card as yours :-) ) Yes, I've notice the yuv run much faster, but I was refering to the basic pix_film. I've only noticed there was a yuv movie player a bit after the last mail. Anyways, can it be used together with all the other pix_ processing stuff?? And are all the rest of the yuv objects in the extra help files you provide? Also I noticed there were to yuv players...
Thnx a lot
Ivan
the basic pix_film uses RGB and it has to convert the yuv data in the compressed video file to RGB, which is quite slow. not all of the pix_ objects can do yuv at the moment, so you might have to use some yuv_ objects right now. if you want to use RGB pix_ objects then i recommend using the Animation codec since it's the only codec that uses compressed RGB. this will remove the slow YUV->RGB conversion. incidentally that conversion was done in hardware by quicktime/quickdraw until recently (QT6 changed it?). i'm trying to figure out how to get it back in OSX. in general the OSX version is really designed to use YUV the whole way, in fact it's the only platform that can do it at the moment.
there are two yuv players (yuv_film and pix_filmYUV) that are identical. since all of the yuv_ objects are in the process of being rolled into the pix_ ones there is the pix_fillmYUV as a transition object. at some point there will probably just be pix_film that does both RGB and YUV based on a message or argument, but right now that doesn't work because openGL doesn't like switching color-spaces on the fly.
docs and a tutorial are really lacking at this point so you'll have to bear with it for the time being. on the other hand if you are a fantastic doc writer maybe you can help out...
cgc
the last part about 'fantastic doc writer' is open to anyone. i personally would prefer a non-developer to write the tutorial because the people writing the code are generally pretty bad about writing 'howto' information. also, some distance from the project might make the whole thing more objective.