[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas and alpha premul color data



On Sat, 24 Jun 2006 00:40:32 GMT,
"jose_ogp@juno.com" <jose_ogp@juno.com> wrote :

> 	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? 

Maybe we could just use premul alpha for image data, because that's the
only critical case where premul alpha color will effectively improve the
perfs, and since, afaik, some image formats already store premul alpha
colors, it's somehow logical. For the other cases, I don't think it's a
good idea to use premul alpha, it will definitively confuse the final
user of evas, and it won't really affect the perfs of Evas I guess.

>  
> > And I forgot to mention another problem I have in mind. 
> >  
> > For now, in edje, if you want to do a color transition from 
> > color1="255 0 0 255" to color2="0 255 0 0", you have to  
> > create 2 states, the first associated to color1, and the second 
> > to color2. 
> >  
> > With "alpha premul" colors, it will become (if I understand  
> > correctly): color1'="255 0 0 255" and color2'="0 0 0 0". 
> >  
> > So how Edje will guess it has to make a transition from red 
> > to green? Or we'll have to keep "normal" colors in edje, but 
> > it won't be coherent with the API of evas :/ 
> >  
> > Simon 
> > 
>  
> 	Ummm, that's odd... Edje should not consider the color 
> 0 255 0 0 as "green". It should be transparent - that's what 
> evas will do with such an input color.. if an obj's color has 
> alpha = 0, the obj is transparent. 
> 	To transition to green one should set color2 to be, 
> green! ie. 0 255 0 255. 
>  
> 	If edje is doing otherwise then it has a bug, or 
> something funky :( 

"0 255 0 255" is indeed transparent, but since you use a smooth
transition, Edje interpolates linearly from "255 0 0 255" to
"0 255 0 255". And so, the "path" to go from "255 0 0 255" to
"0 255 0 255" is not the same than the "path" to go from
"255 0 0 255" to "0 0 0 255", even if in the 2 cases, the starting
and the ending color are the same.

>  
>  
>  
> PS. 
> 	No email that I send to the edev list is getting 
> thru since someone has taken it upon themselves to report 
> me as 'spam' to the spamblock service that the list uses. 
> I don't have the time or desire to screw around with things 
> like this so unfortunately I won't be sending anything to 
> that list as long as that keeps up :( 

Do you want me to forward your messages to the ML?

Regards :)
Simon