[cairo] [Pixman] Floating point API in Pixman

[Bill Spitzak]

Since you are showing that even *pixel operations* can be faster in 
floating point, I think this is a pretty good proof that doing the 
*coordinates* in floating point will be a huge win.

Jonathan Morton wrote:
>>>> I suspect using floats would be *much* better than the existing fixeds
>>>> on modern x86_64 systems.  But fixed will remain important on smaller,
>>>> lighter systems for some time to come.
>>> I believe so too, and I have some actual numbers to back it up.
> 
>> You forgot to attach the numbers. :)
> 
> Well, here is a very brief but representative example:
> 
> (float)  src_8888_8_0565 =  L1: 111.99  L2: 113.84  M:105.89 ( 20.72%)  HT: 64.94  VT: 78.99  R: 55.08  RT: 23.74 ( 329Kops/s)
> (fixed)  src_8888_8_0565 =  L1:  62.29  L2:  63.66  M: 63.02 ( 12.64%)  HT: 59.05  VT: 57.64  R: 52.52  RT: 32.20 ( 446Kops/s)
> 
> Most of the numbers are Mpix/s, the %-age numbers in the middle are of
> estimated available memory bandwidth.  The floating-point path has a
> large (50%+) advantage in throughput, while the fixed-point path seems
> to have less setup overhead which shows up on tiny (8x8) operations.
> 
> And that's not exactly the most complex operation on the table.  In
> fixed-point, it's a multiply by the unified mask followed by a 3-channel
> format conversion.  Much more trivial than that and you get memcpy().
> 
> This is all achieved by using lookup tables to accelerate the
> fixed-to-float conversions (tables are pre-generated up to 16bpc),
> leaving only the store operations to be run through a real
> float-to-fixed converter.

Such tables also allow conversion from sRGB to linear to be done as 
well, producing much nicer composites. I have had pretty good luck using 
the top 16 bits of floating point to do a reverse lookup back to the 
integer values, again this allows conversion from linear to sRGB.