On Mon, 26 Jun 2006 06:37:21 GMT, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote : > The get/set functions that deal with image data would > have to constantly transform from premul to non-premul thus > making the use of these very slow.. also, if you want to work > with the data doing graphics ops yourself, then you would be > better off doing so with it in premul color space, as it's easier > and faster there. > I would say that most here would thus be convinced that > the evas funcs that set/get image data should thus work with the > data assumed to be in premul color space. Yeah, I agree image_data_set/get() could gain from using premul alpha colors. And since image_data_set/get() is not used really often, or mainly with alpha=255, it won't break a lot of things.
> In others, like adding colors to grads, evas could do > different things -- it could generate the spectrum by linearly > interpolating in non-premul color space, then premul that for > compositing, or it could go ahead and transform the inputs > to premul colors and generate the spectrum from those... These two > will not give the same results -- not even close if > there are alphas < 255. > There are ways to approximate the first using the second, > but not the other way around... so, using non-premul colors > directly is actually a restriction on what can be obtained. For grads, I would have thought that using premul colors was actually more restrictive than using non-premul colors, mostly because the conversion from non-premul to premul colors is not reversible (i.e if alpha=0, you can't get back the original non-premul color from the converted premul color). So, how can you make a linear grad from "opaque red" to "transparent green" with premul colors? With non premul colors, you just have to add 2 colors to the grad: "255 0 0 255" for "opaque red" and "0 255 0 0" for "transparent green". In premul colors, there is no "transparent green" (well... I agree, "transparent green" is visually the same color than "transparent red", since it's all transparent...) > In conclusion -- as I see it, there are three possible > paths for "e" as a whole to follow when it comes to this issue > of premul or non-premul color spaces. > > 1. Do nothing - remain with using non-premul as is now > currently the case. > > 2. Move the internals of the graphics stuff to premul, > but leave all, or most, of the interfaces to use non-premul. > > 3. Move as much of elibs/eapps as feasible to use premul > color space. > > > I have tried to give my view above of some of the pros > of going with 3, and why I don't want anything to do with 2. I'd rather be for solution 2, i.e. keep all the API functions use non-premul colors, except image_data_set/get(). 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
