[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[E-devel] Fw: Evas and alpha premul color data
I'm forwarding the messages that Jose sent me because he seems to be
detected as a spammer by the ML service.
----- Forwarded Message -----
Date: Fri, 23 Jun 2006 23:26:21 GMT
From: "firstname.lastname@example.org" <email@example.com>
Subject: Re: [E-devel] Evas and alpha premul color data
> Hi Jose,
> Mm.. It seems to be a very important change indeed. If I understand
> correctly, it means that all the apps that calls
> evas_object_color_set() and every edje theme will have to be
> updated. This is a problem, but it can be quickly solved.
Yes, it sucks... I know. Also every app that calls image_data
set/get as well.
> The most important problem imho is that "alpha premul" colors are
> really less intuitive than "normal" colors, at least for me :)
> For example, when you are designing an edje theme, you often change
> the alpha of a part to try different values, and to see which alpha
> value looks the best. So now, every alpha change will need a change
> of the r, g, b components too, right?
It seems that way because you're so used to thinking in
non-premul terms, but yes that's what will have to happen.. and
either you do it yourself, or evas is going to do it for you behind
your back -- there's no way out of this if evas moves to premul
internally. I prefer that you do it yourself so you know exactly
what's going on, and become comfortable with thinking premul colors.
> Another problem, but maybe I'm wrong on that point, is for
> transition. A simple example, you want an object to fade out.
> For now, you only have to use a timer that makes the alpha of the
> object decrease progressively. It's rather intuive for now.
> But with this change, you'll also have to update the rgb values,
Internally it may detect that you're just changing the alpha
and perform things in special ways to speed things up.. but yes,
you can't arbitrarily decrease the alpha without also decreasing
the colors. Again, if you don't do it.. evas will have to do it
for you behind your back.
However, changing the transparency of an object (image or
whatever), so as to make it fade-in or out, is trivial -- just set
the obj's color to (a,a,a,a) for whatever 'a', that's all there is
to it :)
> For me, if the only advantage is to avoid some confusion inside
> the evas's code (so for now, the evas-user is not confused),
> I think it doesn't worth it. We'll avoid a confusion in the code
> of evas, but we'll probably confuse the user (i.e. the coder that
> uses evas). But maybe i'm wrong on the 2 examples I've given,
> maybe the change is not so important.
> Regards :)
> Simon TRENY <MoOm>
Well, internally there are a *lot* of advantages --
Right now, for the blending functions to work 'well', with some
semblance of speed, when there's dst alpha.. and for the other
render ops besides blend, there's a messy, ugly, slow stuff...
Moving to premul internally would eliminate all this,
get rid of a 65Kb table, and make the software routines easier,
faster, and more accurate.
Also, to get things to work with the xrender engine,
we have to premul all data we hand to xrender pictures since
that's what it expects... same for a cairo engine if someone
ever gets around to finishing that.
So, if doing this internally is the way to go, and I
think it is, then the question is: what about the api interfaces,
specifically, the get/set data and color functions?
In order for the get/set image data functions to have
any usefulness, you'll have to do this with the data being premul,
or it'll be so SLOW as to be worthless. Also, if you want to work
with image data yourself, then having it premul is the way to go
as it makes doing graphics operations easier, faster, ...
Ok, then what about the color set/get? Either evas assumes
that you're setting premul colors (ie. satisfying a >= r,g,b) or it
has to force them to be so. What would you prefer?