[cairo] keeping paths as doubles through high-level backend interface

[Vladimir Vukicevic]

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?

     - Vlad