On Sun, 2 Jul 2006 12:35:34 +0900, Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote :
> 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. I don't really like the idea of having a couple of functions, evas_colorspace_set/get() to change the global colorspace of evas. In my opinion, it will confuse the things a bit more and will make the implementation harder. For example, if I start in the colorspace EVAS_COLORSPACE_ARGB_PREMUL, I set the colors of the objects, the data of the images, and then, I switch the colorspace EVAS_COLORSPACE_ARGB. What do I get when I'll try to get the colors or the data of the objects? Converted colors or the old premul colors? Another confusing situation with edje: if I render an edje object in the ARGB_PREMUL colorspace, will it look the same in the ARGB colorspace (i.e. will Edje directly evas_object_color_set() or will it convert the color?) Imho, the colorspace in which the data of an image is internally stored by Evas should depend on the engine used. For example, the software and the xrender engines should store it in premul colors, the OpenGL engine should store it in "normal" colors (since I don't think you can have a premul argb texture, but I'm probably wrong) and a XV engine (stupid idea...) should store it in YUV colors. That way, it will be stored the most efficient way in order to be rendered efficiently. There must be some scaling issues but I dont think that storing in an unique colorspace would solve it (since you'll have to do the conversion sooner or later, probably before the scaling transform if you want to benefit from the optimizations of the engine). So I think that an API like that could be good: void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace); void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing); So it's up to the user to choose the colorspace, (using ARGB_PREMUL to avoid a conversion with the 2 most common engines: software and xrender), and he can't be confused since it's he who makes the choice. Now, there is the problem of evas_object_color_set(). Imho, we have to choose, either we ask always for a premul color or always for a non-premul color, but I don't really like the idea of having a function evas_colorspace_set() to switch the current colorspace (and I don't like the idea of having a colorspace by object too). And if we'll have to choose, I'm still for non-premul colors!! :) Regards, :) Simon TRENY <MoOm> 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
