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

[Blake B. <sh...@na...>]

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

> On Wed, 5 Jul 2006 15:43:54 -0700 Blake Barnett  
> <sh...@na...> babbled:
>
>> On Jul 5, 2006, at 7:49 PM, jos...@ju... 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