From: Chlor commits to subversion <chlor-commits@li...> - 2008-07-08 19:30:44
Date: 2008-07-08 12:28:34 -0700 (Tue, 08 Jul 2008)
CRect runs with float values, all other object of chlor run with doubles. With that, the bounding box can get in some cases smaller than the actual graphic inside.
Algorithms, which rely on the property, that everything is truly inside, get in trouble. A prominent example is the algorithm to check for "insideness". It calculates the intersections of a line from the point in questions to the right border of the bounding box. As the latter may be smaller, the algorithm can't detect the insideness.
a) Adapt the "insideness" algorithm - quick fix, but the problem may remain unnoticed in other areas.
b) Add methods to CRect to add coordinates in double precision.
c) Rewrite CRect completly with double precision.
Solution a) seems to be currently superior, as we wont break other implementations.
--- trunk/src/core/CPath.m 2008-05-15 19:53:15 UTC (rev 560)
+++ trunk/src/core/CPath.m 2008-07-08 19:28:34 UTC (rev 561)
@@ -313,8 +313,14 @@
[segment numberOfIntersectionsWithLineX1: x
- x2: [shapeBoundary right]
+ x2: nextafterf([shapeBoundary right], [shapeBoundary right] +1)
+ // The shapeBoundary is stored in a CRect, which uses float to store
+ // the coordinates. When converting doubles (from the "rest of the Chlor-world"
+ // some roundoff happens. In some cases, the shapeBoundary gets a little
+ // smaller than it should be, causing this code to fail.
+ // To get on the safe side, we use next bigger representable float
+ // number here.
// The point (x,y) lies inside the path if the number of segment intersections with the
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.