> > we need the ability to have image objects in different > colrospaces yugv(and its variants, yuv422, yuv420, etc. etc.) > is a long-term must. the ENGINE has to deal with yuv data. > if it can't it can always use the yuv import calls internally > to RGBA then do it all in RGBA land - but if the subsyetm > (gl/xrender/etc.) can do yuv natively - then do it that way, > hoping the hw accel does a much better job than we do. adding > in ARGB non-premul as another colorspace is merely convenience > as its just the SAME logic as handling a yuv image object - > having to convert to a native format before using it. in fact > its probably the thing we would want to test with to start with. > yuv would get support later. >
Let's agree on one thing: The gfx operations, unless otherwise explicitly stated, will be done in premul argb color space, or a linear equivalent of it.. Ok, fine.. and actually premul ayuv would be ok too since when decoded yuv is linearly related to rgb (hsv eg. is not). There's already such an interface to set imported data from yuv, and moving the 'conversion' to rgb down to the engines is fine as they may simply be able to deal with it directly, etc.. That's all good, and an interface for importing yuv to image data is already there, you can extend it to cover any premul ayuv format type with no problem. But, "setting" a color space, either globally or per obj, has only one real meaning - that the color space in question is going to be used as the current context for gfx ops. Doing this for non premul anything, is shear folly. Any 'benefit' you claim can be obtained for apps/libs that want to deal with non-premul color spaces by deferring premultiplying till it may be needed and whatnot.. is microscopic compared to the confusion, complexity, etc. caused by this misrepresentation. Now, you can argue that maybe not "setting", but rather "importing", non-premul color space formats for conversion is ok.. But I don't see anything worthwhile in providing such interfaces for data and/or colors, and just see an increase in complexity in dealing with that internally and, again, microscopic gains. Let's assume that edje has been modified to pass premul colors/data to evas, and eet saves premul data, and that evas provides premul/non-premul conversion api functions for colors data.. Just where exactly in e17 would there be even minor pain caused by evas being premul only? What about entrance, ewl/etk, etc....? jose. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel