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

[Vladimir Vukicevic]

On Nov 2, 2007, at 4:44 PM, Behdad Esfahbod wrote:

> On Fri, 2007-11-02 at 18:58 -0400, Vladimir Vukicevic wrote:
>> 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.
>
> Thanks for bringing this up.  I hit this issue again last week, and  
> it's
> really bad.  Just have a surface with a deivce_offset.x of > 32000 and
> you simply can't draw anything to it.  Including text using gdk!
> Because even cairo_get_current_point() is broken...

Ouch!  That's pretty bad, I wasn't even thinking of that particular  
interaction.

>> 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.
>
> Please go ahead.  That should fix most of our 16.16 issue.  As much  
> that
> we may be able to get away with it and postpone 24.8 switch for later.
>
>> 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.
>
> Sounds like a good plan.
>
>> Does this sound like a good plan?
>
> Really good one.  Looking forward to reviewing it.

Ok, I'll get started.

>
>>     - Vlad
>
> PS.  What needs to be done in the 24.8 branch?  Can we get that moving
> too?

It's already been merged (a while ago) -- the only thing needed to do  
the switch is to change the #define in cairo-fixed-private.h, and to  
double check what happens on linux.  We've already done the switch in  
mozilla's cairo version and haven't seen any ill effects yet.

     - Vlad