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

Re: [E-devel] Premul move -- decisions and such




On Jul 5, 2006, at 6:11 PM, Carsten Haitzler (The Rasterman) wrote:

On Wed, 5 Jul 2006 15:43:54 -0700 Blake Barnett <shadoi@nanovoid.com> babbled:

On Jul 5, 2006, at 7:49 PM, jose_ogp@juno.com wrote:
<snip>


	This would allow evas to remain purely within the realm
of non-premul color space and have more-or-less the same results
with the xrender engine as with the software engine.

	The benefits of this would of course be that there would
be no "pain" on any of the current apps/libs using evas.
	The detriments are a klunky, slower, more limited rendering
model.
<snip>

I can understand the distaste for a klunky model, but has there been
any profiling done to show just how much of a speed loss we're
talking about with this implementation?  From my perspective as
purely an Evas user, I would FAR prefer to have no API changes and an
insignificant performance hit than a huge API change, and an
insignificant performance gain.

the gains when dealing with xrender which in the long run when finally hardware acceleration ceases to suck and actually accelerates, will be worth it alone. now we deal in the same native colorspace xrender works in so we dont have to convert every time we interface with it. as for other speedups - when rendering to an argb dest buffer we get about 10-20% speedups easily from memory. its doesn't include the fact that premul will make scaling of argb data look more correct with speedups as opposed to needing to add more branches into the scaler in order to try and make it correct for non-premul which will slow it down. we possibly could gain better compression for storing image/ pixel data
too etc. etc.

its worth it.

Cool, just had to ask.

-Blake