[cairo] towards 24.8

[Vladimir Vukicevic]

Carl Worth wrote:
> On Mon, 18 Jun 2007 13:27:05 -0700, Vladimir Vukicevic wrote:
>> So I've got this working!  The current work in progress is in the 
>> fixed-24-8 branch in my tree 
>> (git://git.cairographics.org/~vladimir/cairo I believe).
> 
> I haven't looked at the code yet, but Vladimir asked me to take a
> quick look at the performance impact. So I compared current HEAD
> (02f753c2) to what's currently in his fixed-24-8 branch (7ecff8b3).
> 
> He was expecting no speedups, but perhaps some slowdown due to
> copying/converting from 24.8 to pixman/X's 16.16.

Yep, thanks for looking into this!  The branch is actually still in 
16.16 mode, though switching it to 24.8 shouldn't make a difference 
performance wise.  I was expecting slowdowns because in a bunch of 
places I have to copy stuff around that was previously just passing a 
buffer straight down into pixman, though I made sure to stack allocate 
buffers where appropriate.

> Here are the results I got from several runs (that is, I kept running
> things until the results stopped changing).
> 
> I'm not sure how meaningful things are here. Some comments:
> 
>  * The pattern_create_radial test does stress the double_to_fixed
>    conversion code, and that has certainly changed, (but only in which
>    magic numbers are used, not the arithmetic, right?). But also, the
>    standard deviation values are larger than the performance difference
>    for some of those, (though, again, I couldn't make these speedups go
>    away no matter how many times I ran the test). Anyone care to look at
>    the resulting assembly code for double_to_fixed and guess if a speedup
>    is possible?

fixed_from_double (and all other fixed-point functions) are now inlined; 
before it was a function call, so I can believe a speedup here.  (I 
forgot that I inlined all of those when I figured there would be no 
speedups :)

>  * It's strange to see the rectangles test as both a speedup and as a
>    slowdown, (but note that it's reporting a speedup for xlib and a
>    slowdown for the image backend). Any theories for that?

No theories offhand.. I'll take a look and see what's going on.

>  * The 10% slowdown for paint seems the most worrisome. Perhaps with a
>    quick look at some profiles for that.

Yup, this is pretty odd; I'll take a look at the code visually and also 
see about profiling.

Thanks,
     - Vlad