[cairo] keeping paths as doubles through high-level backend interface
vladimir at pobox.com
Fri Nov 2 15:58:57 PDT 2007
Before I start coding this up, I wanted to get opinions on whether
this was a good idea, and any problems that might come up. (I think I
wrote about this a while back, but it may have been in part of a
different thread -- I can't find the post at the moment.
Right now, cairo users specify path coordinates and operations using
doubles; these doubles are then transformed by the CTM (using fp
math), and then they are converted to fixed point for storage.
However, many backends would prefer to have the full precision
floating point number available -- PS, PDF, SVG, Quartz are the
initial ones that come to mind. I propose changing the normal path
storage and the backend API interface such that the doubles are stored
directly, and a conversion function to a fixed point path is provided
when a fixed path is currently needed (or maybe not -- maybe we should
just use the double-to-fixed routines wherever necessary). That is,
fallback_stroke,fill,etc. would do the conversion from double->fixed
before continuing. This shouldn't affect any current users,
especially on platforms with a FPU, as the conversion would still take
place, just at a different time. However, even those platforms would
end up benefitting from higher fidelity PS/PDF output.
We could even take this a step further and define a cairo_path_coord_t
and a handful of helper macros; if that type was used instead of
doubles, it then becomes much easier to create a version of cairo that
uses fixed point arithmetic for all operations -- which may be
interesting to platforms that lack a FPU.
Does this sound like a good plan?
More information about the cairo