[PD-dev] [GEM] more on YUV (was: postrendering crashes)

[chris clepper]

>Quoting tigital <tigital at mac.com>:
>>  ...don't worry:  we're still here!  Just got quiet for awhile during
>>  a little break ;-)
>>
>>  ...I think chris and I have come around to putting everything into
>>  pix_*, but that means there will be alot of objects that don't have
>
>hey !
>sounds like christmas has come back again....
>very happy that this (yes: tiresome) discussion is obviously coming to an end.

Did you read the rest of what he said?

At 2:22 PM -0500 1/7/03, tigital wrote:
>but that means there will be alot of objects that don't have
>rgba functionality, which is kinda useless on macs now; also, I think
>it'd be to everyone's advantage to move to YUV processing

So that means someone will have to get cracking on the rgba code end 
for 40+ yuv_ processing objects.  Which brings up another point about 
developing code for two color-spaces: does this require all 
developers to write their objects for both or do we just wait for 
someone to eventually come along and finish the implementation? 
Also, one developer might not know how to write yuv code and thus 
writes only rgb versions.  Or another developer thinks yuv stuff is 
the only way to go and can't be bothered to write rgb versions.  So 
now we have a large difference in which platforms can do what using 
the exact same objects.  This is precisely the thing you have been 
railing against lately right?

The idea of auto-conversion in each object when one object lacks the 
code for one color space is a bad idea.  The performance hit will be 
quite high and at that point you might as well do software openGL 
rendering as well.

So what other options does this leave?  Dumping endless error 
messages in the console?  Require the user to have lots of conversion 
objects in the render chain?  How is the difference between the two 
made clear on the docs and in the pd patcher?  And what clues will 
GEM give the user to alter the patch to preform correctly? I don't 
think an adequate solution has been devised yet.

cgc

>mfg.as.rd
>IOhannes
>
>_______________________________________________
>PD-dev mailing list
>PD-dev at iem.kug.ac.at
>http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev


--