Geometry Boost List: [ggl] Clipping/Intersecting efficiency

Subject: [ggl] Clipping/Intersecting efficiency
From: Koying Bing (koying)
Date: 2009-05-29 09:54:51

Thanks for trying to help.

While registering the point* the indicated way pass compilation, I now have
the problem that, at run-time, the output points are created on the stack,
which obviously fails on a pointer.

Is there a way to somehow define the creator for the point* ?

- Chris -

2009/5/29 Barend Gehrels <Barend.Gehrels_at_[hidden]>

>  Hi Chris,
>
> Welcome to the list!
>
>
> Profiling my application (Merkaartor, which uses, notably, ggl to do
> linestring clipping), I came to realize that clipping takes about 70% of the
> time it takes to draw a frame!
>
> That is too bad indeed.
>
>
> 2 reasons for that:
>
>  1) My "linestrings" are vectors of POINTERS to points.
> I didn't find a way to use pointers as valid point_2D, so I have to
> recreate a linestring_2D before intersecting -> malloc -> poor performance.
> Is there a way to use a std::vector<point*> as a linestring?
>
>
> That must be possible, using traits classes. You have to register a point*
> as a valid point, implementing the traits classes with access methods to get
> and set the coordinates. c01_custom_point_example.cpp is an example, but
> there are registration macro's used, probably you cannot use those. So then
> it will be something like (from a sample with a 3D point "my_color" with
> fields red,green,blue):
>
> namespace ggl { namespace traits {
>
> template<> struct tag<my_color>
> { typedef point_tag type; };
>
> template<> struct coordinate_type<my_color>
> { typedef double type; };
>
> template<> struct coordinate_system<my_color>
> { typedef cs::cartesian type; };
>
> template<> struct dimension<my_color>
>     : boost::mpl::int_<3> {};
> template<>
> struct access<my_color>
> {
>     template <std::size_t I>
>     static double get(const my_color& p)
>     {
>         return I == 0 ? p.red : I == 1 ? p.green : p.blue;
>         // Or implement an accessor with specializations
>     }
>
>     template <int I>
>     static void set(my_color& p, const double& value)
>     {
>         // Or (better) implement an accessor with specializations
>         if (I == 0) p.red = value;
>         else if (I == 1) p.green = value;
>         else if (I == 2) p.blue = value;
>     }
>
> };
>
> }} // namespace ggl::traits
>
>
> (If you have your sources from boost, replace ggl:: by geometry::, this is
> from the new version).
> If you need help with it I can create another sample with a point* or a
> template-wrapper around a point*
>
> 2) intersecting uses outputstream to store its results. This again means
> malloc -> poor performances.
> Would it be possible to have an option to use a callback function returning
> the ordered result?
>
> The output iterator is the most generic option. The first version outputted
> to a multi-line, but now programmers can decide themselves what to do with
> it (multi-line, console, etc). However, it internally has to append points
> to lines. It is probably also possible to specialize also that one for
> specific situations -> this will probably have the same effect as a
> callback.
>
>
>
> Other programming practice suggestions are obviously welcome.
>
> Having the point* (or a template-wrapper around it) registered as a point,
> and a vector<point*> as a linestring, you should be able to call all
> ggl-algorithms more naturally.
>
> Regards, Barend
>
>
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090529/0faf5e7e/attachment-0001.html