Similar to my last post, You will loose precision when casting from float to int or NRShort (whatever that is).
In desktop-snap.c if all the code is doing is figuring out the slope, then perhaps dx? and dy? should be floats as well. What happens if the slope is less than 0.5? Would we catch it? I don't know what dx and dy are used later for, so maybe it has to be this way.
When doing transformations you want to keep numbers as floats for as long as possible and only convert them to ints when they finally need to be plotted to the screen. Otherwise you loose precision and you may find that after a few rotate transformations, your object is not only rotated, it has also shifted position slightly.
Cheers, Rob. http://members.rogers.com/rcrosbie
From: "Jon A. Cruz" <jon@...18...> To: inkscape-devel inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Bug: Number type warnings Date: Wed, 12 Nov 2003 11:02:47 -0800
Jon A. Cruz wrote:
Bryce Harrington wrote:
Noticed some warnings during the build... Someone want to look into this and make a patch?
Sure. Me.
Here are patches for 840539 and 840543
(I noticed more problems, since I compile within emacs and it's easy to search the scrollback. I'll probably get on those too)
Index: libnrtype/nr-rasterfont.c
===================================================================
RCS file: /cvsroot/inkscape/inkscape/src/libnrtype/nr-rasterfont.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 nr-rasterfont.c
--- libnrtype/nr-rasterfont.c 30 Oct 2003 02:22:53 -0000 1.1.1.1
+++ libnrtype/nr-rasterfont.c 12 Nov 2003 18:50:17 -0000
@@ -315,16 +315,16 @@
if (nr_font_glyph_advance_get (rf->font, glyph, &a)) { switch (slot->type) { case NRRF_TYPE_TINY:
slot->glyph.tg.advance.x =NR_MATRIX_DF_TRANSFORM_X (&rf->transform, a.x, a.y);
slot->glyph.tg.advance.y =NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y);
slot->glyph.tg.advance.x =(NRShort)(NR_MATRIX_DF_TRANSFORM_X(&rf->transform, a.x, a.y));
slot->glyph.tg.advance.y =(NRShort)(NR_MATRIX_DF_TRANSFORM_Y(&rf->transform, a.x, a.y));
break; case NRRF_TYPE_IMAGE:
slot->glyph.ig.advance.x =NR_MATRIX_DF_TRANSFORM_X (&rf->transform, a.x, a.y);
slot->glyph.ig.advance.y =NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y);
slot->glyph.ig.advance.x =(NRShort)(NR_MATRIX_DF_TRANSFORM_X(&rf->transform, a.x, a.y));
slot->glyph.ig.advance.y =(NRShort)(NR_MATRIX_DF_TRANSFORM_Y(&rf->transform, a.x, a.y));
break; case NRRF_TYPE_SVP:
slot->glyph.sg.advance.x =NR_MATRIX_DF_TRANSFORM_X (&rf->transform, a.x, a.y);
slot->glyph.sg.advance.y =NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y);
slot->glyph.sg.advance.x =(NRLong)(NR_MATRIX_DF_TRANSFORM_X(&rf->transform, a.x, a.y));
slot->glyph.sg.advance.y =(NRLong)(NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y));
break; default: break;Index: desktop-snap.c
===================================================================
RCS file: /cvsroot/inkscape/inkscape/src/desktop-snap.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 desktop-snap.c
--- desktop-snap.c 30 Oct 2003 02:20:11 -0000 1.1.1.1
+++ desktop-snap.c 12 Nov 2003 18:19:18 -0000
@@ -116,8 +116,10 @@
/* Determine which way a set of three points winds. */
{
int dx1, dx2, dy1, dy2;
dx1 = p1.x-p0.x; dy1 = p1.y - p0.y;dx2 = p2.x-p0.x; dy2 = p2.y - p0.y;
dx1 = (int)(p1.x - p0.x);dy1 = (int)(p1.y - p0.y);dx2 = (int)(p2.x - p0.x);dy2 = (int)(p2.y - p0.y);/* compare slopes but avoid division operation */
if(dx1*dy2 > dy1*dx2) return +1; // ccw
This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
_________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2...
Robert Crosbie wrote:
Similar to my last post, You will loose precision when casting from float to int or NRShort (whatever that is).
In desktop-snap.c if all the code is doing is figuring out the slope, then perhaps dx? and dy? should be floats as well. What happens if the slope is less than 0.5? Would we catch it? I don't know what dx and dy are used later for, so maybe it has to be this way.
When doing transformations you want to keep numbers as floats for as long as possible and only convert them to ints when they finally need to be plotted to the screen. Otherwise you lose precision and you may find that after a few rotate transformations, your object is not only rotated, it has also shifted position slightly.
Except that freetype uses only fixed point arithmetic.
njh
participants (2)
-
Nathan Hurst -
Robert Crosbie