[Gambas-user] Clipper counter-intuitivities

Tobias Boege taboege at ...626...
Sat Jun 27 16:21:13 CEST 2015


On Fri, 19 Jun 2015, Beno?t Minisini wrote:
> Le 18/06/2015 20:38, Tobias Boege a ?crit :
> > Hi Benoit,
> >
> > the attached project shows two strange behaviours of Polygon from the
> > gb.clipper component.
> >
> >   (1) Polygon._get() returns a new PointF object created on the fly from
> >       internal data. However, people would think that
> >
> >         hPolygon[0].X = 20
> >
> >       should modify the zeroth point's x coordinate to 20, which it doesn't
> >       in the current implementation. Can't we cache the PointF objects such
> >       that changes to the return values of _get() are updated into the
> >       Polygon?
> >
> 
> To do that, we have to replace the PointF by a specific class 
> (PolygonPointF?) that is like PointF, but owns a reference on the 
> Polygon, so that updating the point updates the polygon.
> 
> There is the same trick with the Control.Font class, so that it behaves 
> the way you describe.
> 
> But it's heavy: it uses one pointer more for the two floating point 
> coordinates. So I don't really like it.
> 

Also it would be a bit ugly to have a new PointF class. My idea was to have
a lazy cache for points: in _get() look into the cache if the indexed point
is there. If not, allocate it, fill it with clipper's data, put it into the
cache and return the object. You know how that works. This way, for each
point there will always be one object which is referenced inside the Polygon
object. The two gigantic drawbacks are: (a) data is duplicated in the cache,
as it will also be in the clipper library's objects, and (b) we would have
to write the cache back into the clipper objects before virtually any
operation.

How about the following: _get() returns a virtual .Polygon.Point class. This
mechanism already carries around the pointer to the Polygon object most
efficiently. Property changes can easily be transferred into the clipper
library. To get a real PointF object, we can spend a GetPoint() method and
to have something like _put(), we add a SetPoint(hPoint As PointF) method.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk




More information about the User mailing list