[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cairo
Subject:    Re: [cairo] git "performance" patchset # 1 available + a few questions
From:       David Reveman <davidr () novell ! com>
Date:       2006-06-22 20:27:13
Message-ID: 1151008033.27686.31.camel () localhost
[Download RAW message or body]

On Thu, 2006-06-22 at 09:51 +0200, David Turner wrote:
> Hello,
> 
> the git patchset corresponding to the performance enhancements described 
> on my web page[1]
> is now available at:
> 
>   http://turnerdavid.neuf.fr/desktop/dturner-performance-1.patchset
> 
> sorry, it took me a long time to get it right, mainly because of lack of 
> time. I have also a few
> questions:
> 
> - I have some prototype code to moderately speed up the gradient 
> rendering code. Before
>   providing it, I'd like to understand why, in the pixman gradient code, 
> a 'stopRange' field
>   containing the constant value 0xFFFF is being used to deal with padding ?
> 
>   By using a constant 0x10000 for the equivalent of "stopRange", it's 
> possible to get rid of
>   one 64-bit division per pixel, plus some hideous modulo operations (in 
> case of padding),
>   and I would find this a worthy optimization. This introduces no 
> distinguishible difference
>   to the eye, but of course, it fails the Cairo test suite.
> 
>   Is there something I'm missing in the pixman/Cairo API that would 
> prevent us from doing
>   this in the current implementation ?

The original gradient code is from the X server and written by Lars
Knoll. It was using a color table and produced very incorrect results in
some cases. To be able to use this code with cairo, I changed it so it
didn't use a color table but made sure it was flexible enough to allow
use of a color table once we have some code that figures out if it can
be used without producing incorrect results.

Some time since I looked at that code but 'stopRange' field is probably
related to this.

0x10000 for stopRange is probably fine. If you find that removing any of
the color table support speeds things up, that's fine with me too.

> 
> - on my home machine (a Pentium M latop with an Intel 855G graphics 
> "card"), the "cairogears"
>    benchmark indicates that the Cairo image backend is about twice 
> faster than the XRender one
>    (except for the TEXT2 benchmark).

Cause is probably read backs from video memory and that (without my
server-side gradient patch) gradients are generated on client side and
passed to the server as images, which means that we compute a lot more
gradient pixels than necessary, not only the ones that will end up on
screen after compositing.

-David


_______________________________________________
cairo mailing list
cairo@cairographics.org
http://cairographics.org/cgi-bin/mailman/listinfo/cairo
[prev in list] [next in list] [prev in thread] [next in thread]