On Sun, 2 Jul 2006 23:57:15 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > > > 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.. agreed - with possible FUTURE ability to use more esoteric colorspaces like YUV (though frankly yuv is handled most sanley by a convert to yuv first - BUT you can actually get speedups combining the scale and convert at the same time) > 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. sure - and i would suggest we expand it to also import non-premul ARGB - thats basically all i was really suggesting. :) > 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. oooh no - for me it means that became the api with which u dealt with evas. evas internally would do whatever it damn well pleased. :) the only guarantee u had is that u could present data in format X and get it back in format X. what happend later was entirely out of scope and goign to happen in premul ARGB. > 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? every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) 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
