[cairo] Keeping the current point as floating-point

[Owen Taylor]

On Fri, 2005-08-19 at 16:51 -0700, Carl Worth wrote:
> As part of looking at the following bug:
> 
> 	https://bugs.freedesktop.org/show_bug.cgi?id=4137
> 
> I looked into what it would take to not have things like
> cairo_rel_line_to, (and by extension cairo_rectangle), round
> intermediate floating-point values to fixed-point.
> 
> Here's the patch I came up with, which stores the current point within
> the path as a double rather than a cairo_fixed_t. It also changes all
> of the path-construction functions to accept doubles instead of
> cairo_fixed_t.
> 
> Because of that, the name cairo_path_fixed_t didn't make much sense
> anymore, (OK the path is still stored in fixed-point, but it seems the
> object name should reflect the external interface more than internal
> storage), so the patch also renames cairo_path_fixed_t to
> cairo_path_device_t, (since its interface is in device space as
> opposed to cairo_path_t which is in user space).
> 
> The renaming does make the patch much bigger than the important stuff
> happening here. Use the information in the ChangeLog to find the
> interesting bits if you care to review.
> 
> I don't know how significant this fix is. I don't think we have any
> known bugs that would be fixed by this. So it may make sense to just
> hold off on this patch until after 1.0 to avoid any new bugs it might
> have.
> 
> This patch will cause tests to start "failing", as the patch does
> actually change a few pixels in some results. In all of the tests we
> have so far, the results both before and after the patch look
> perfectly acceptable to me.

Looking through the patch, I see only two problems:

 1) I don't see how the changes to cairo-ft-font.c work:

====
 static int
 _move_to (FT_Vector *to, void *closure)
 {
-    cairo_path_fixed_t *path = closure;
+    cairo_path_device_t *path = closure;
     cairo_fixed_t x, y;

     x = _cairo_fixed_from_26_6 (to->x);
     y = _cairo_fixed_from_26_6 (to->y);

-    _cairo_path_fixed_close_path (path);
-    _cairo_path_fixed_move_to (path, x, y);
+    _cairo_path_device_close_path (path);
+    _cairo_path_device_move_to (path, x, y);

     return 0;
 }
====

 And so forth - we seem to be passing fixed point coordinates in
 where doubles are expected. (I wonder if 'sparse' could easily be
 used to catch conversions from fixed => double or fixed => int
 without going through one of our conversion functions?)
 
 This of course brings up the issue that we'll be doing a lot more
 int => double => int conversions here... would it make sense to alow
 the current point to be *either* fixed or double, or is that to 
 much complexity?

 2) cairo-win32-font.c will need fixes too.

Didn't see any other problems. No comment comment on whether this makes
sense pre-1.0.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050822/32c2d813/attachment-0001.pgp