On Sun, 2 Jul 2006 12:00:03 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> 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!! :) ok - with a lot of time, thinking, other things to occupy me, etc. i have actually given this thought. here is my current view. 1. i think we can handle a switch to premul for argb pixel data and color_set and gradients etc. edje itself would translate non-premul to premul when loading an edje config file as non-premul makes more sense to humans (artists) as it is what they are used to. -- ------------- 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