On 6/23/06, email@example.com <firstname.lastname@example.org> wrote:
> 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?
Mainly 'because I can' :)
Because not all of my image data gets handed over to Evas. Sometimes it stays in a memory buffer. I also handle my own caching (I know, don't reinvent the wheel, but my application required several priorities of caching so I moved it up an abstraction level), so I use Imlib2 to load the data in a buffer, and assign that buffer to an Evas image if needed.
I also do this because I'm not always sure of the internal implementation of the hardware GL backend of Evas (I've never really went deep into the code). For example I always thought gradients were handled by the standard interpolation OpenGL does on a triangle or quad. Since Evas now supports radial gradients I assume it works differently. For the same reason I'm not sure, and I haven't taken the time, to dig into the code to find out if image data is always stored in memory of the graphics card, even if it is hidden. That would mean I could load 2 gigs of image data in temporary buffers myself if I have 4 gigs of ram, but possibly couldn't load them all in evas images if it tries to pump it into 256 megs of texturing memory on my graphics card. My knowledge may be too little here and I'm getting sidetracked :)
> 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?
There's a good patch floating around I'm aware of. I'm a lazy Gentoo user so I just 'emerge' from the latest CVS, and last time I did that the specific patch wasn't integrated there.
> 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?
I use Imlib2 for loading PNGs in a memory buffer and operating on that [drop shadowing, reflection shadowing, etc...]. I believe in choosing the right tool for the job, and I'm quite certain Imlib2 is better optimized than cairo for such things. I only use cairo when I have to.
> 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.
Reflection or fade-out over images would need changes. I do this with simple alpha value manipulations now. I would need to use all components in that case (probably making the routine slower, but judging by your changes that probably would cancel out in Evas then).
> 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 :)
You're right. I should make it uniform. I always feel premultiplied alpha to be a bit counter-intuitive :) I just like to manipulate the alpha and fade things in and out. But that's a feeling I suppose :)
Manipulating the r, g and b components with certain factors still feels icky to me most of the time. I always feel I'm losing accuracy by manipulating integer values in that way. I haven't really written out on paper if this would actually give visual artifcats, but it still seems like a 'speed vs quality' tradeoff.
I mainly based my stance on the premultiplied subject sometime ago by information from this post concerning cairo:http://community.livejournal.com/evan_tech/146495.html
Especially 'advantages of non-premultiplied' in that post. Again I stress that I haven't dug into the subject matter deeply, so I may have the wrong viewpoint on this thing.