[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