[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: "jose_ogp@juno.com" <jose_ogp@juno.com>
To_: simon.treny@free.fr
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.