> > 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.
>
>
> I'm starting to come around, but am still slightly hesitant.
> I think there are two ways you can view the colors in question.
>
> A) Color of a 'physical' canvas object that has a separate
> 'transparency' property. "Graphic Artist"
>
> B) The color of the individual pixels that gets drawn to the screen.
> "Graphic Programmer"
>
> In (A) we are thinking in non-premul terms. E.g. we have a green
> rectangle (rgb = 0 255 0) that is then faded to 50% (a = 128).
> So, we think combine these into argb = 128 0 255 0.
>
> However, what is ACTUALLY happening (as you've pointed out), is that
> the opaque object has argb = 255 0 255 0, and the fading to a=128
> applies to the color vector as a whole. e.g argb = 128 0 128 0.
> This view is more closely related to (B).
>
Yes, that's a good way to put it I think. Also, one should
note that the concept of "alpha" is not always really best seen
as equivalent to "opacity" -- this is really a good interpretation
for ops that are 'additive' in nature.. In general, alpha is really
more like an "intensity" or "brightness" of some kind, and modulates
the rgb color components.
> As an (illustrative?) aside, an interesting case: antialiased text.
> We tell some text that we want to be green that it has a color of
> 255 0 255 0. For the opaque parts this is true in both models.
> Now, the AA parts of the text have alpha < 255. Currently, we think
> of this as just affecting the alpha bit of the pixel. So, every
> pixel fo the text (in non-premul terms) has rgb = 0 255 0.
> In premul terms the 'rgb' piece of the color vector is no longer
> constant throughout the text. Anyway, just an interesting difference
> between the two color models.
>
Yes. Actually aa text gives a basic example of a non-trivial
"shape" which we have to color or texture in order to display it.
We obtain the glyphs as alpha-masks, ie. arrays of alpha data only,
no rgb color data, and then we have to decide what it means to render
this to some dst image with some argb texture data (usually just a
single color).
If we were to multiply the argb texture data with the glyph
alpha mask, then we obtain a new argb texture 'fitted' to the glyph
shape which we can then use for as our src image rendering...
However, this only really works well for 'additive' kinds
of rendering ops. In general, we actually use the glyph alpha mask
as a linear interpolator between the dst image and the result of
op(src-texture, dst).
This is kind of a pain to do with the xrender engine for
some ops with external masks, as it likes to intertwine the mask
and src pictures... but it can be done. It's not in the evas xrender
engine yet, pending the move to premul and a restructuring of the
image drawing pipeline.
> >
> > 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.
> >
>
> For a lot of these, we might need two sets of API functions.
> Of course, we then get to argue over which is 'default' (e.g.
> which does evas_object_color_set() use). For grads, if specified
> in non-premul terms, that means build the spectrum entirely in
> non-premul THEN convert.
>
That's a possibility.. there may be other ways too. I just
don't want to have "here it's this.. but you can do something else
there, because who knows why this one is special but not that one.."
I would prefer that evas not modify its api color inputs,
so that what-you-give-is-what-is-used (more or less), and consistent
in its use of color data.
Keith Packard had an interesting idea for a mechanism that
would allow one to obtain this with premul inputs and not have to
go thru the work of generating extra premul grad stops to obtain
such results.. namely, we add to grads the ability to specify alpha-
only stops as well as premul argb color stops. We can do this easily
in evas, with software only if need be (and that's how we're doing
grads right now since only the latest xrender versions support grads
at all).
> > 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....
>
> This makes sense to me. Evas is (essentially) a compositing engine,
> so the colors it uses should be described in compositing (premul)
> terms. But edje is a graphic design tool, so its colors should be
> described in 'normal' (non-premul) terms. I gaurantee you you're
> not going to convince designers to use premul colors. They don't
> make sense in the "green object with fifty percent transparency"
> mindset.
Agreed. I prefer this as well. I don't think a rendering
engine should be subservient to any "holy spec", wether it be
the enlightened edc or the sacred svg or the magnificent MSAvalon..
It should allow for any number of 'higher level libs' to be able
to realize as many such as possible.
> >
> > 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.
> >
> >
>
> Maybe the 2.5 case you mentioned above? Evas in 100% premul terms
> and edje / higher level apis not? (or 2.25 - which includes an
> additional non-premul api to evas for convenience)
>
> --
> brian
>
How about 2.5, with the extra addition of a simpler
mechanism for obtaining "non-premul grads" kinds of results
as suggested above (although you could do this by generating
the spectrum yourself in non-premul space, premul the result
and pass it to the grad api via the grad 'data_set' api func).
One is then free to have libs which decide to have
interfaces with premul, or non-premul, or a combination,
as they see fit... and evas will be able to support them.
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
