[cairo] [PATCH] Rely less on fast double-precision FPUs

Bill Spitzak spitzak at gmail.com
Wed Jun 2 10:51:34 PDT 2010


A single-precision float cannot hold all the values that can be 
represented by any 32-bit fixed-point format. For the recommended 24.8 
format that I think Cairo is switching to, values outside the range 
±65535 will lose lower-order bits compared to 24.8.

Double-precision can store any value in any 32-bit fixed-point format 
losslessly.

Matrix multiplication almost has to be done in floating point as the 
intermediate results can be huge. Use of doubles for the matrix and all 
the intermediate results should make the resulting fixed-point value be 
accurate, so I figure that is why this was chosen.

I'm not sure if you should be relying on huge offsets working. Lots of 
back ends probably do things in floating point anyway. If this is common 
then Cairo could prehaps try to solve this by subtracting these offsets 
so that only small values are passed to the back end, this is a solution 
we have had to do with OpenGL wrappers because of users expecting huge 
translations to work:

This involves somehow decomposing the matrix into an integer translation 
and a floating-point remainder. If M is the floating point and T the 
integer translation, the cairo matrix is equivalent to M*T (not M+T 
which is a lot easier to implement but useless...)

cu wrote:
> Probably because of range? Cairo has enough trouble with large values
> that do not fit into the "fixed point" representation. Limiting them
> further to 32 bit float would make life even harder. Some of us draw
> using really really large numbers (with surface offset appropriately
> shifted :) ).


More information about the cairo mailing list