My thanks to Simon for forwarding some emails while I am
spam, and thanks to everyone for the feedback on this premul
color deal :)
I've gone over this a bit, and I'd like to recap here
what I think about all this.
It's definitely a 'plus' for evas to move with working
in premul color space internally (and recall: a,r,g,b is premul
iff a >= r,g,b). There are many reasons for this.. some I've
already stated here [and BTW: this was all raster's idea to
begin with - please send many nasty emails to him].
If we accept this and move that way, then the question
becomes: How would this affect apps/libs using evas, and what
do we do about it?
Any function that gets/sets color data will be affected,
one way or another... some in 'minor' ways, some in 'big' ways -
both performance wise and semantic wise.
Since most here are used to working with non-premul colors,
and thus most 'legacy' stuff assumes that.. it will seem like a
terrible idea to move to working with premul colors, and would
prefer that evas would this all internally and keep everything
the same otherwise.
This however leads to problems since as mentioned above
the internal use of premul colors affects things one way or
another.
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.
However, when it comes to the funcs that deal with just
single colors, most seem to be reluctant to come to a similar
conclusion.
There are several functions that deal with setting
individual colors - setting an obj's color, setting the text
style colors, adding colors to grads, ... and there are likely
to be more to come.
In some of these, evas cannot directly use the non-premul
colors in any way, so it would just transform the input color to
a premul one. The only effect these have is thus one level of
indirection -- what you input is not really what gets used.
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.
I can't see any benefit to having the inconsistency
of data get/set being premul but color get/set being non-premul.
All I see is indirection and untold confusion and limitations
arising from this latter.
One could put any use of non-premul colors up to
'higher level' libs if they find interfacing with non-premul
colors to be "good" somehow...
In particular, we might think that edje would benefit
from this.. and indeed Simon has pointed out an example where
it would seem to be easier to have non-premul colors in the
edc format: the use of "linear transitions" from one color
to another to set an object's color.
If edje were to use premul colors, then such transitions
would seem to be difficult to obtain....
Well, they could be approximated by several linear
transitions, if edje/edc were to work with premul colors only..
but this may seem like to much work for some.
However, there are better ways.
One thing you should realize is that these "linear"
transitions are not really linear at all in the resulting
display color space if there's alpha involved.. and in fact
it would be impossible to obtain linear transitions of premul
colors.
If you really want to have this capability, and extend
it to something more powerful as well, then it would be easy
to do with edje/edc using premul color space.
We can add "quadratic" transitions (or even any spline
based one), all one needs to specify this would be the start and
end colors of course (premul now), c0, c1 say, and a 'control'
color cc say.
The premul color at a given time t, for t in [0,1], is
then given by:
c(t) = t*t*c1 + 2*t*(1-t)*cc + (1-t)*(1-t)*c0;
This would give you all the capabilities of the current
non-premul case... and more.
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.
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
