[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 :/
On Fri, 23 Jun 2006 15:44:42 +0200,
Simon TRENY <firstname.lastname@example.org> 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,
> "email@example.com" <firstname.lastname@example.org> 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 email@example.com
> > 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
> _______________________________________________ enlightenment-devel
> mailing list firstname.lastname@example.org