[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas and alpha premul color data
It would certainly break a lot of my code. I currently have some manual bindings of various evas objects to Ruby, and large chunks of code that implicitly require nonpremultiplied alpha.
I suppose using premultiplied alpha would also break things like loading ARGB32 data directly from Imlib2 to Evas by hand (I frequently use that method to display images), since IIRC PNG data for example is not premultiplied.
Also, I frequently use an 'evas-cairo' object of my own that simply uses an evas image as its surface and responds to cairo calls (I mostly use this for displaying SVGs in Evas and as a fallback for gradients since they got broken in Evas). For this reason I explicitly implemented a de-premultiplier (since cairo uses premultiplied alpha on its surfaces as well).
Additionally I have several routines that 'drop-shadow' and 'reflect-shadow' some Evas images by accessing the buffer itself, so that would also break with premultiplied alpha.
I wouldn't recommend against it, but I'd highly prefer some global flag which can be set that would allow developers to choose between the two. Or if necessary, a flag on an object-per-object basis that can be overridden if needed.
On 6/23/06, email@example.com <firstname.lastname@example.org
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"
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
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
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.
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