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: [EMAIL PROTECTED] [EMAIL PROTECTED]
To_: [EMAIL PROTECTED]
Cc: enlightenment-devel@lists.sourceforge.net
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,
no?!
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?
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel