Re: [Lib2geom-devel] Path translations

[<jbc...@sw...>]

Hi Nathan,
  To be frank, I'd appreciate it if you'd read my first mail again, and look up the relevant bits of code, because your reply does not make much sense ;-) :P

Short summary:
1.  Is it OK to add the (first non-const) member function to Curve:  Curve::operator+=(Point)
     - This *forces* all Curve-descendants to be closed under Translation. This is the case for all current descendants, I'd like a second opinion on a possible design error that hurts us later on.
2.  Path currently stores its Curves in shared_ptr<vector<shared_ptr<const Curve>>>
     For more efficient Translates, the "const" is problematic and currently I have to used a const_cast. If we remove the const, we loose an important compile-time check, but the const_cast is pretty ugly I find...

Thanks,
  Johan



---- Nathan Hurst <nj...@nj...> wrote: 
> I thought we had specialised Matrix types translate, scale etc which
> you could just specialise the templates on.  (indeed I think if you
> use templates here it should 'just work')
> 
> njh
> 
> On Tue, Nov 12, 2013 at 01:18:16AM +0100, Johan Engelen wrote:
> > Hi all,
> >    Currently, when translating a path (adding a point), 2geom treats it 
> > as any other affine transform. This is quite a performance hit.
> > 
> > (refresher:
> > Path is a collection of Curves. A Curve is a virtual base for many curve 
> > types. Because many curve types are not closed under affine transforms 
> > (the result after an affine transform can not always be represented as 
> > its original Curve type, e.g. HLineSegment after rotation), when 
> > transforming a Curve, a new Curve is created that holds the transform. 
> > When transforming a path, each Curve is transformed, and thus a bunch of 
> > new Curves are created.
> > )
> > 
> > As far as I can see now, all (current) Curve types *are* closed under 
> > translations. I think we should enforce this for Curve. I.e., each Curve 
> > must implement
> >         virtual Curve &operator+=(Point const &);
> > I tested the performance increase for special-casing Translate 
> > transforms, by adding
> >        Path &operator*=(Translate const &m) {
> >          *this += m.vector();
> >          return *this;
> >        };
> >        Path &operator+=(Point const &m);
> > next to the current
> >        Path &operator*=(Affine const &m);
> > Of course, more changes were needed, and so far I have only implemented 
> > addition for BezierCurveN, just to see the performance increase.
> > 
> > After the change, the path-operations test runs more than twice as fast.
> > 
> > Do you have any concerns about enforcing an operator+= implementation 
> > for Curves ?
> > Interestingly, *all* member functions of Curve are const.
> > operator+= would be the first state-changing member function. :)
> > 
> > Cheers,
> >    Johan
> > 
> > 
> > ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models. Explore
> > techniques for threading, error checking, porting, and tuning. Get the most 
> > from the latest Intel processors and coprocessors. See abstracts and register
> > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Lib2geom-devel mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel