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

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



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.


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)