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

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



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


On Fri, 23 Jun 2006 15:44:42 +0200,
Simon TRENY <simon.treny@free.fr> wrote :

> 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. 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?
> 
> 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?!
> 
> 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>
> 
> 
> On Fri, 23 Jun 2006 06:20:47 GMT,
> "jose_ogp@juno.com" <jose_ogp@juno.com> wrote :
> 
> >   
> > 	Just a note to all here..  
> >   
> > 	Sometime within the next week or three, I may send a very  
> > large evas patch (probably in 3 or 4 parts) which entails a very  
> > *drastic* semantic change for evas --- namely, it will support  
> > only "alpha premultiplied" image data and colors which are given  
> > in argb format.  
> >   
> > 	This would cause some pain, and break some things.. but in  
> > the long run, I believe it is better.  
> >  
> > 	However, one has to learn to think in/with "alpha premul" 
> > colors.  
> >   
> > 	What does this mean????  I'll explain it a bit here.  
> >   
> > 	In argb color space where colors are specified by 4-tuples  
> > a, r, g, b, representing the alpha, red, green, and blue
> > components of a color, that this is an 'alpha premul' color means
> > that the alpha component 'a' has value >= the r,g,b components.  
> >   
> > 	That's all it means, nothing more.  
> >   
> > 	One way to obtain an alpha premul color from any color,  
> > is to replace the old r,g,b values by new r',g',b' values given by  
> > r' = (a*r)/255, g' = (a*g)/255, b' = (a*b)/255, hence the term  
> > "alpha premultiplied".  
> >   
> > 	Where will evas be affected by this? Anywhere you see
> > image or gradient objects take argb32 data... this data will now
> > be *assumed* to be alpha premul by default. If you pass in data,
> > or specify colors, that are *not* premul, then you will get mostly  
> > junk results.  
> > 	Similarly, any api function that refers to setting a color  
> > on an object somehow, it will now be assumed that the color is  
> > alpha premul.. If they aren't, you will get mostly junk results.  
> >   
> > 	"Why not simply keep the interfaces to accept non premul  
> > colors, as is now the case, and just do things internally with  
> > premul if that's such a great thing...?"   
> >   
> > 	Because mixing premul and non-premul color spaces leads to  
> > immense amounts of confusion, and is error prone..  
> > 	I have seen very knowledgable and experienced people get  
> > wrapped around in the confusion caused by this.  
> >   
> > 	Learn to think with alpha premul colors, this may seem  
> > drastic.. and it is indeed.. but it's far more consistent for a  
> > wide variety of things, and even more 'natural' once one gets used  
> > to the change.  
> >   
> >   
> > 	If this change seems unacceptable to most here - and I can  
> > certainly understand that - or would prefer some mixture of premul  
> > and non premul... that's fine, I will leave evas alone then.  
> >   
> > 	But I personally want nothing to do with mixing these two  
> > color spaces. It's a bad idea.  
> >   
> >   
> >    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
> > 
> 
> 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
>