Some notes on optimization work in progress (was: Re: [cairo] WinXp benchmarks)

[David Reveman]

On Fri, 2005-03-04 at 00:46 +0100, Soeren Sandmann wrote:
> David Reveman <davidr at novell.com> writes:
> 
> > Either way it seems like the gradient calculations are quite expensive.
> > The first thing we should do is check that no larger gradients than
> > necessary are created, after the recent changes that made so that
> > patterns are passed to the backends, I'm no longer sure that the size is
> > optimal. The second thing we could do is to hook up simple optimizations
> > for vertical and horizontal gradients as Owen suggested recently.
> 
> Even for non-axis aligned gradients, we should be able to do better:
> 
>   For each line of pixels compute the relevant color stops and their
>   positions, then for each sub-gradient just do a simple linear
>   interpolation using a floating point factor.

yes, I guess doing linear gradients in spans could speed things up.  

>  
> 
> I haven't actually written the code and tried it, so I could be wrong
> of course.
> 
> (Why is it that we can't use the GPU shader for this?)

Oh, we can, the glitz backend is doing almost every gradient supported
by cairo using shaders, if hardware supports it of course. But there's a
lot of hardware that doesn't support shaders and a fast software
implementation is always useful. 

I can easily accelerate simple 2-stop linear gradients on hardware
without shader support in the glitz backend, just haven't got around
doing that yet.

> 
> > Looking at gearflowers.svg and SVGs in general, it seems that most
> > patterns are solid or gradients and that should always end in this
> > composite operation:
> > 
> > SRC(argb32, no transform) in MASK(a8 shape, no transform) op
> > DST(probably ARGB32 or 32bpp RGB24)
> > 
> > We should be able to accelerate that pretty well, right?
> 
> Yeah.

good, I think that could make a big difference.

btw, I rendered gearflowers.svg with rsvg. Just to see how bad 6.5s
rendering time really is. Turned out rsvg needed 36s to render it.

$ time svg2png gearflowers.svg gearflowers.png 
real    0m6.597s
user    0m6.179s
sys     0m0.078s
$ time rsvg gearflowers.svg gearflowers.png 
real    0m36.217s
user    0m34.732s
sys     0m0.230s

so maybe 6.5s isn't that bad after all.

-David