render improvements

Zack Rusin zack at kde.org
Fri Apr 15 17:35:20 PDT 2005


On Friday 15 April 2005 20:14, you wrote:
> On Friday 15 April 2005 10:10, Lars Knoll wrote:
> > Hi,
> >
> > Zack and myself have in the last two weeks worked on improving
> > performance the general composition path in the render extenstion
> > (the code in fbcompose.c).
>
> Nice work!
>
> This fails rendercheck (from /cvs/xapps) for a few transformations
> and for the component alpha case.  I don't know whether that's a bug
> in your code or in rendercheck but we should verify it.

Component alpha or external alpha? I thought we nailed all the problems 
with component alpha. I changed a little bit the external alpha. The 
old implementation had a bug in which a picture with external alpha 
composed with a another picture with uniform alpha was producing a 
different result than two pictures with uniform alpha composed together 
(assuming the first composed picture is the same in both cases, just 
its alpha handling differs). I made the output image come out the same 
in both cases. I'm not sure if I'd like to try to reproduce the old 
behavior because, well, because it produces different outputs for two 
practically same inputs.
As to the others do they happen with a4b4g4r4 and x4b4g4r4 visuals? We 
fixed those as well. I'll recheck that later.

> The benchmark numbers you posted look good for the general case but
> are marginally slower for Over blends, which will probably be 90% of
> Render usage.  I suspect this is a result of not using the MMX path.

Right. The super-fancy special casing is not in ;) Once Owen commits the 
MMX code to xserver we'll merge that back in and I'll add some AltiVec 
code because we just can't have PPC trailing behind, can we? ;)

Zack

-- 
Nostalgia: The good old days multiplied by a bad memory...



More information about the xorg mailing list