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