On Thu, 29 Jun 2006 08:24:48 -0500 [EMAIL PROTECTED] babbled: Ok - time to jump in on this thread.
1. premultiply does speed things up in the internal engine. it also would speed up dealing with xrender as we then deal in xrender's native ARGB colorspace. premul makes sens from many viewpoints. 2. yes - it WORKS differently to non premul space. it literally is a different colorspace with alpha and a transition from 1 colors that vary alpha in premul does NOT work (always) the same as non-premul. thats how it works. a lot of points within a linear traversal in premul and non-premul space can be linear, but others can't. as simon pointed out - that is a case where the linear path in premul does not match non-premul. this is something i think we can live with. 3. premul solves some of our existing up and downscaling problems where we interpolate the COLOR to whatever rgb is off in the blank pixel next to a solid pixel. you will notice sometimes blackish halos or sometimes colored ones. it depends on the source pixels loaded. often you don't notice - but it's something i have noticed and this fixes it with no performance impact (and actually speedups). 4. xrender works in premul. right now when copying evas pixel data to xrender we need to do a premul process. its not very optimised, but it works and goign to premul internally will allow us to save this step IF the source image fromat is premultiplied (i will add eet code to do this actually as then edje files with image data can have all the data already pre-processed). 5. changing the pixel format to premul wont impact a lot - only things that directly access image ARGB pixels via get/set data will be affected, and then only if they use the alpha channel. 6. the problem we have is for evas_color_set() and then edje and nigh everything that depends on this. if we go premul for this just about everything will break and need fixing. this is a lot of stuff. what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). then we can begin a migration of code over to premul and remove the call - but still keep it there for the ability to switch into a more convenient colorspace. i am not sure this colorspace should affect image pixels though... that should be per image object as above. -- ------------- 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
