[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.
Yes, it would. You would have to premul the data prior
to handing it to evas.
> 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.
Evas can load png images.. Why do you need to use imlib2
to load them?
> 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).
Gradients are still broken? Ummm... They seem to work
"ok" for me (in the very limited tests I've had a chance to put
them thru). What problems exactly are you having with them?
> For this reason I explicitly implemented a de-premultiplier
> (since cairo uses premultiplied alpha on its surfaces as well).
Well, you wouldn't need that then, as evas would expect
premul data as well.
Also, why do you need both imlib2 *and* cairo to 'draw'
stuff? What are you drawing with imlib2 that cairo can't?
> 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.
They may not need any changes.. check the code and see
wether or not you really need non-premul for the algos to work,
or if they may just need minor changes.
> 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.
A flag to set wether or not the data you set or get
is premul would in effect be useless to evas if it's only
going to work with premul data internally -- all evas would
do is premul or un-premul the data.. might as well do that
The point is that non-premul data is a pain to deal
with and should be avoided - move your work over to premul
and you may be happier :)