lib2geom-devel — development discussion

Re: [Lib2geom-devel] BezierCurve fun :-(

[Krzysztof K. <twe...@gm...>]

2011/2/13  <J.B...@ew...>:
> I do not see what exactly we gained by making them all BezierCurve (no
> templating).

See previous mail, right now I can iterate over a path and treat every
Bezier in a generic way instead of treating each order like a distinct
type of curve.

> The only reason I see is that now the code can talk about
> BezierCurves and not care about their order. But for most stuff, one can
> already do that by talking about Curves instead. The only methods that
> are new to BezierCurve (compared to Curve) are:
> order()
> points(), setPoint(...), and setPoints(...)
> operator[]

The points() and setPoints() methods are extremely important, as they
give you full access to the definition of the curve, whereas the
methods of Curve do not. You can't reconstruct a Bezier curve in a
straightforward way using only the information provided by the Curve
interface.

> If we need that, then I think it is better to revert to the template
> case with BezierCurve<1> and BezierCurve<2>, etc, and derive those from
> a class BezierCurveGeneral (or something like that), which contains
> these general methods (virtual).

I tried to do this, but I couldn't write any meaningful code in
template<int order> BezierCurve. I had to put all optimizations in
template specializations: template<> BezierCurve<3>. Therefore the
template is useless, and its only reason for existence is aesthetic.

Regards, Krzysztof

Re: [Lib2geom-devel] BezierCurve fun :-(

[Krzysztof K. <twe...@gm...>]

2011/2/12  <J.B...@ew...>:
> Hi all,
>
> At the moment, Inkscape is suffering a bit from changes to LineSegment,
> QuadraticBezier and CubicBezier; this is not so much a problem. But I
> want to be sure that 2geom is heading where we want it to go.
>
> Right now, LineSegment, QuadraticBezier and CubicBezier are derived from
> BezierCurve. This is nice, because many methods have identical
> implementations (taking their order() in to account).  For example:
>    virtual Curve *transformed(Affine const &m) const {
>        BezierCurve *ret = new BezierCurve(order());
>        std::vector<Point> ps = points();
>        for(unsigned i = 0;  i <= order(); i++) ps[i] = ps[i] * m;
>        ret->setPoints(ps);
>        return ret;
>    }
> (why does this method not have return type BezierCurve* ?)

Because this method is virtual, and the type signature has to match
the superclass method. Otherwise it would not be called if you wanted
to invoke it from a pointer to Curve.

> However.
> Class LineSegment implements its own transform method.
>    virtual Curve *transformed(Affine const &m) const {
>        return new LineSegment(initialPoint() * m, finalPoint() * m);
>    }
> Why is this so? Perhaps for performance reasons. LineSegment actually
> overrides many methods of BezierCurve, while QuadraticBezier and
> CubicBezier don't. Is the performance argument not valid for higher
> order beziers?

This is done for two reasons:
1. The returned object has to be of type LineSegment, not BezierCurve
2. It is slightly faster, as you mentioned.

> (...)
> This all leads to the question: why do we have the QuadraticBezier and
> CubicBezier classes? Why don't we simply delete them? They create a
> false impression of optimized/special classes.; and more importantly,
> the API becomes ambiguous.

This is certainly an option. The only reason to keep these is that
most people new to computational geometry don't know that a line
segment is a special case of a Bezier curve, and would expect to find
a line segment class in the library.

For example: let line and cubic be of type
> LineSegment and CubicBezier. Then,
>   Curve *line_reverse = line.reverse();
>   Curve *cubic_reverse = cubic.reverse();
> The question is: what type is line_reverse, and what type is
> cubic_reverse? It turns out that line_reverse is of type LineSegment*,
> and cubic_reverse it *not* of type CubicBezier*, but BezierCurve*.
> Similar for cubic.transform(), derivative(), etc.

This is an oversight, of course the returns should have the correct
specialized types.

> There is a BezierCurve::optimize() method
> that converts a BezierCurve to a CubicBezier if order()==3. But this
> method is very prone to result in memory leaks, and I would advise
> anybody against using it (let's remove it from the code, really!).

I was thinking this could maybe be useful when someone wants to avoid
creating a new object if possible, but now it doesn't seem worth the
trouble to me - the method is too prone to incorrect use.

> Perhaps we should remove the definitions for Cubic and QuadBezier.
> Instead of
>   if  ( CubicBezier *cubic = dynamic_cast<CubicBezier*>(curve))
> isn't it nicer to write
>   if  ( curve.order() == 3)
> ?

It's even better to define static functions or methods:
is_bezier_curve, is_line_segment, is_quadratic_bezier,
is_cubic_bezier. For API orthogonality, the same static functions
could be defined for other curve types: is_sbasis_curve,
is_elliptical_arc.

> If we want to keep CubicBezier and QuadBezier, there should be a good
> way to convert between the two. The optimize() method should become
> memory consistent (now the user does not know whether a new object is
> created or not).

Right now the duplicate() method works in this way - it automatically
returns the correct specialized type.

> Summarizing my questions:
> 1. Do we loose much performance by not providing special functions for
> Cubic and QuadBezier?

Probably not.

> 1a. If not, then why don't we delete these classes? This makes it much
> clearer for users.

Deleting LineSegment actually makes the library less clear as
described before (not everyone knows that a line segment is a
first-order Bezier), so I would try to preserve at least LineSegment.

> 2. Is it correct that we should demote the use of dynamic_cast and
> promote the use of order()==3?

dynamic_cast didn't work for me when I fixed the Node tool to work
with the new 2Geom BezierCurve class. I think it's best to define the
is_some_curve_type static functions to avoid his sort of question.

> What was the reason to switch from the templated BezierCurve (i.e.
> typedef BezierCurve<3> CubicBezier) to what we have now?
> It seems to have created quite a mess :-(

The old code made it impossible to refer to a Bezier curve of
arbitrary order in a generic way. If you wanted to precess a path
segment by segment, you had to have dynamic_cast switches for every
possible order of Bezier curve you could encounter; in effect, every
order of a Bezier behaved like a different class that had nothing in
common with other orders, which is a very bad abstraction.

Regards, Krzysztof

Re: [Lib2geom-devel] BezierCurve fun :-(

[<J.B...@ew...>]

> -----Original Message-----
> From: Nathan Hurst [mailto:nj...@nj...]
> Sent: 13 February 2011 02:10
> To: Engelen, J.B.C. (Johan)
> Cc: lib...@li...
> Subject: Re: [Lib2geom-devel] BezierCurve fun :-(
> 
> On Sat, Feb 12, 2011 at 10:59:37PM +0100, J.B...@ew...
> wrote:
> > Hi all,
> >
> > At the moment, Inkscape is suffering a bit from changes to
> LineSegment,
> > QuadraticBezier and CubicBezier; this is not so much a problem. But
I
> > want to be sure that 2geom is heading where we want it to go.
> 
> Excellent post!
> 
> I have always felt that general degree solutions are better than
> special cases.  With the exception of linesegments, there are no
> benefits to using special case code other than perceived compiler
> optimisation opportunities.  The original motivation was that there
> were a few special case tricks for quad and cube cases (solving them
> in closed form was the main one; but our general purpose root finders
> and intersectors are now as fast as the closed forms for at least the
> cubic case).
> 
> The other reason for special casing is the fact that there are a
> number of algorithms which only produce one kind, and people have good
> intuition for the behaviour of cubics (end points and tangents).
>
> > However.
> > Class LineSegment implements its own transform method.
> >     virtual Curve *transformed(Affine const &m) const {
> >         return new LineSegment(initialPoint() * m, finalPoint() *
m);
> >     }
> > Why is this so? Perhaps for performance reasons. LineSegment
actually
> > overrides many methods of BezierCurve, while QuadraticBezier and
> > CubicBezier don't. Is the performance argument not valid for higher
> > order beziers?
> 
> Perhaps we should do some actual profiling.  I suspect that these
> special cases are valuable, mostly for cache/register reasons.
> 
> Lines also have a very simple dual form which we switch back and forth
> from all over the place.  The dual space (implicit curve)
> representation of higher order polynomial curves is rapidly
> unmanagable and generally avoided. (quadratic is used rarely).
> 
> > The only methods that are overridden by QuadB and CubicB are
"virtual
> > Coord length(Coord tolerance) const;". And actually, BezierCurve
> itself
> > calls the same internal method as the special QuadB and CubicB
> > functions. The overhead in BezierCurve::length is checking the order
> of
> > the curve, and if it is 2 or 3, it calls the specialized function
for
> > QuadB or CubicB.
> 
> There is no good reason to special case the length calculation -
> either we want a fast approximation or exact.  The fast case can be
> something like interval(start to end distance, sum of handle lengths)
> for a simple and efficient pair of bounds.  The exact case is not
> closed form for anything but lines (even the length of a quadratic
> requires trigonometric functions which are numerically computed rather
> than exact).
> 
> > This all leads to the question: why do we have the QuadraticBezier
> and
> > CubicBezier classes? Why don't we simply delete them? They create a
> > false impression of optimized/special classes.; and more
importantly,
> > the API becomes ambiguous.
> 
> I agree.  But people expect there to be cubic and quadratic.  I say we
> dump them.
> 
> So the real problem to solve is the memory management and
> compactness.  This is an area I have little expertise in, perhaps
> Krystof or you can propose a memory model for our data structures that
> is efficient, leak free, and easy to use?  In some way, this has been
> the biggest struggle for 2geom from the begining.  And we still
> haven't solved it :)
> 
> > The only reason, I can think of now, to keep CubicBezier and
> QuadBezier,
> > is that it makes it possible to write methods that require a bezier
> > curve to be of specific type. I.e., one could write a method
> >   void specialmethod(CubicBezier &cubic) {
> >    ...
> >   }
> > that explicitly only accepts BezierCurves of order 3. Much better
> than
> >   void specialmethod(BezierCurve &cubic) {
> >     assert(cubic.order() == 3);
> >     ...
> >   }
> 
> Yes, but I don't think we have many of those.  We do have some
> functions which only produce a single type.  The most crucial would be
> the various fitting algorithms which reduce a general curve into low
> degree approximations.
> 
> > Summarizing my questions:
> > 1. Do we loose much performance by not providing special functions
> for
> > Cubic and QuadBezier?
> 
> Needs to be profiled, but my intuition says not commensurate with the
> cost to the api.
> 
> > 1a. If not, then why don't we delete these classes? This makes it
> much
> > clearer for users.
> > 1b. If yes, then we should provide special case methods for Cubic
and
> > QuadBezier!!!
> 
> Agreed
> 
> > 2. Is it correct that we should demote the use of dynamic_cast and
> > promote the use of order()==3?
> 
> I don't know, not my expertise.  I would like to make an effort to
> make large paths of low degree curves to be efficient.  This probably
> means some kind of packing.  But that packing should not be visible.

Thanks for your quick response Nathan.
Right now, I am actually against the change that happened, so I'd like
to revert it back to what we had.
We used to have general degree solutions in code, and the compiler would
generate special cases from them by templating. So we had BezierCurve<3>
for CubicBezier for example.
I do not see what exactly we gained by making them all BezierCurve (no
templating). The only reason I see is that now the code can talk about
BezierCurves and not care about their order. But for most stuff, one can
already do that by talking about Curves instead. The only methods that
are new to BezierCurve (compared to Curve) are:
order()
points(), setPoint(...), and setPoints(...)
operator[]
subdivide
If we need these special methods to be available without knowing the
exact order of the curve, e.g.
     BezierCurve bla = dynamic_cast<BezierCurve> getCurve...;
     bla.subdivide
instead of dynamic casting to each of the common bezier orders...
If we need that, then I think it is better to revert to the template
case with BezierCurve<1> and BezierCurve<2>, etc, and derive those from
a class BezierCurveGeneral (or something like that), which contains
these general methods (virtual).

Right now, effectively we lost Quad/CubicBezier as classes and it to me
it seems a pity.
But I think we have to wait until Krzysztof is back, and makes a
comment.

Ciao,
  Johan

Re: [Lib2geom-devel] BezierCurve fun :-(

[Nathan H. <nj...@nj...>]

On Sat, Feb 12, 2011 at 10:59:37PM +0100, J.B...@ew... wrote:
> Hi all,
> 
> At the moment, Inkscape is suffering a bit from changes to LineSegment,
> QuadraticBezier and CubicBezier; this is not so much a problem. But I
> want to be sure that 2geom is heading where we want it to go.

Excellent post!

I have always felt that general degree solutions are better than
special cases.  With the exception of linesegments, there are no
benefits to using special case code other than perceived compiler
optimisation opportunities.  The original motivation was that there
were a few special case tricks for quad and cube cases (solving them
in closed form was the main one; but our general purpose root finders
and intersectors are now as fast as the closed forms for at least the
cubic case).

The other reason for special casing is the fact that there are a
number of algorithms which only produce one kind, and people have good
intuition for the behaviour of cubics (end points and tangents).

> However.
> Class LineSegment implements its own transform method.
>     virtual Curve *transformed(Affine const &m) const {
>         return new LineSegment(initialPoint() * m, finalPoint() * m);
>     }
> Why is this so? Perhaps for performance reasons. LineSegment actually
> overrides many methods of BezierCurve, while QuadraticBezier and
> CubicBezier don't. Is the performance argument not valid for higher
> order beziers?

Perhaps we should do some actual profiling.  I suspect that these
special cases are valuable, mostly for cache/register reasons.

Lines also have a very simple dual form which we switch back and forth
from all over the place.  The dual space (implicit curve)
representation of higher order polynomial curves is rapidly
unmanagable and generally avoided. (quadratic is used rarely).

> The only methods that are overridden by QuadB and CubicB are "virtual
> Coord length(Coord tolerance) const;". And actually, BezierCurve itself
> calls the same internal method as the special QuadB and CubicB
> functions. The overhead in BezierCurve::length is checking the order of
> the curve, and if it is 2 or 3, it calls the specialized function for
> QuadB or CubicB.

There is no good reason to special case the length calculation -
either we want a fast approximation or exact.  The fast case can be
something like interval(start to end distance, sum of handle lengths)
for a simple and efficient pair of bounds.  The exact case is not
closed form for anything but lines (even the length of a quadratic
requires trigonometric functions which are numerically computed rather
than exact).

> This all leads to the question: why do we have the QuadraticBezier and
> CubicBezier classes? Why don't we simply delete them? They create a
> false impression of optimized/special classes.; and more importantly,
> the API becomes ambiguous. 

I agree.  But people expect there to be cubic and quadratic.  I say we
dump them.

So the real problem to solve is the memory management and
compactness.  This is an area I have little expertise in, perhaps
Krystof or you can propose a memory model for our data structures that
is efficient, leak free, and easy to use?  In some way, this has been
the biggest struggle for 2geom from the begining.  And we still
haven't solved it :)

> The only reason, I can think of now, to keep CubicBezier and QuadBezier,
> is that it makes it possible to write methods that require a bezier
> curve to be of specific type. I.e., one could write a method
>   void specialmethod(CubicBezier &cubic) {
>    ...
>   }
> that explicitly only accepts BezierCurves of order 3. Much better than
>   void specialmethod(BezierCurve &cubic) {
>     assert(cubic.order() == 3);
>     ...
>   }

Yes, but I don't think we have many of those.  We do have some
functions which only produce a single type.  The most crucial would be
the various fitting algorithms which reduce a general curve into low
degree approximations.

> Summarizing my questions:
> 1. Do we loose much performance by not providing special functions for
> Cubic and QuadBezier?

Needs to be profiled, but my intuition says not commensurate with the
cost to the api.

> 1a. If not, then why don't we delete these classes? This makes it much
> clearer for users.
> 1b. If yes, then we should provide special case methods for Cubic and
> QuadBezier!!!

Agreed

> 2. Is it correct that we should demote the use of dynamic_cast and
> promote the use of order()==3?

I don't know, not my expertise.  I would like to make an effort to
make large paths of low degree curves to be efficient.  This probably
means some kind of packing.  But that packing should not be visible.

njh

Re: [Lib2geom-devel] BezierCurve fun :-(

[<J.B...@ew...>]

> -----Original Message-----
> From: J.B...@ew...
> Sent: 12 February 2011 23:00
>
(snip)
> Instead of
>    if  ( CubicBezier *cubic = dynamic_cast<CubicBezier*>(curve))
> isn't it nicer to write
>    if  ( curve.order() == 3)
> ?

I think it is nicer, however, most often 'curve' will be of type Curve
and first has to be dynamic_cast to BezierCurve :-(. So the code
becomes:
   BezierCurve *bezier = dynamic_cast<BezierCurve*>(curve);
   if  ( Bezier && bezier.order() == 3)
which is very cumbersome... :-(

What was the reason to switch from the templated BezierCurve (i.e.
typedef BezierCurve<3> CubicBezier) to what we have now?
It seems to have created quite a mess :-(

-Johan

[Lib2geom-devel] BezierCurve fun :-(

[<J.B...@ew...>]

Hi all,

At the moment, Inkscape is suffering a bit from changes to LineSegment,
QuadraticBezier and CubicBezier; this is not so much a problem. But I
want to be sure that 2geom is heading where we want it to go.

Right now, LineSegment, QuadraticBezier and CubicBezier are derived from
BezierCurve. This is nice, because many methods have identical
implementations (taking their order() in to account).  For example:
    virtual Curve *transformed(Affine const &m) const {
        BezierCurve *ret = new BezierCurve(order());
        std::vector<Point> ps = points();
        for(unsigned i = 0;  i <= order(); i++) ps[i] = ps[i] * m;
        ret->setPoints(ps);
        return ret;
    }
(why does this method not have return type BezierCurve* ?) 
By implementing these 'general' methods for BezierCurve, people can
create BezierCurves with arbitrary order, very nice. And the code
becomes more compact and is more easily verified.

However.
Class LineSegment implements its own transform method.
    virtual Curve *transformed(Affine const &m) const {
        return new LineSegment(initialPoint() * m, finalPoint() * m);
    }
Why is this so? Perhaps for performance reasons. LineSegment actually
overrides many methods of BezierCurve, while QuadraticBezier and
CubicBezier don't. Is the performance argument not valid for higher
order beziers?

The only methods that are overridden by QuadB and CubicB are "virtual
Coord length(Coord tolerance) const;". And actually, BezierCurve itself
calls the same internal method as the special QuadB and CubicB
functions. The overhead in BezierCurve::length is checking the order of
the curve, and if it is 2 or 3, it calls the specialized function for
QuadB or CubicB.

This all leads to the question: why do we have the QuadraticBezier and
CubicBezier classes? Why don't we simply delete them? They create a
false impression of optimized/special classes.; and more importantly,
the API becomes ambiguous. For example: let line and cubic be of type
LineSegment and CubicBezier. Then,
   Curve *line_reverse = line.reverse();
   Curve *cubic_reverse = cubic.reverse();
The question is: what type is line_reverse, and what type is
cubic_reverse? It turns out that line_reverse is of type LineSegment*,
and cubic_reverse it *not* of type CubicBezier*, but BezierCurve*.
Similar for cubic.transform(), derivative(), etc.  The user can never be
sure that the CubicBezier he once created will stay accessible as such
(please excuse the language I am using). After some operations on a path
containing CubicBeziers, a dynamic_cast<CubicBezier> on a path segment
is almost certain to fail. There is a BezierCurve::optimize() method
that converts a BezierCurve to a CubicBezier if order()==3. But this
method is very prone to result in memory leaks, and I would advise
anybody against using it (let's remove it from the code, really!). 
Perhaps we should remove the definitions for Cubic and QuadBezier.
Instead of 
   if  ( CubicBezier *cubic = dynamic_cast<CubicBezier*>(curve))
isn't it nicer to write
   if  ( curve.order() == 3)
?

The only reason, I can think of now, to keep CubicBezier and QuadBezier,
is that it makes it possible to write methods that require a bezier
curve to be of specific type. I.e., one could write a method
  void specialmethod(CubicBezier &cubic) {
   ...
  }
that explicitly only accepts BezierCurves of order 3. Much better than
  void specialmethod(BezierCurve &cubic) {
    assert(cubic.order() == 3);
    ...
  }

If we want to keep CubicBezier and QuadBezier, there should be a good
way to convert between the two. The optimize() method should become
memory consistent (now the user does not know whether a new object is
created or not).

Summarizing my questions:
1. Do we loose much performance by not providing special functions for
Cubic and QuadBezier?
1a. If not, then why don't we delete these classes? This makes it much
clearer for users.
1b. If yes, then we should provide special case methods for Cubic and
QuadBezier!!!
2. Is it correct that we should demote the use of dynamic_cast and
promote the use of order()==3?

Thanks, 
  Johan

Re: [Lib2geom-devel] SBasis questions

[<J.B...@ew...>]

> -----Original Message-----
> From: Nathan Hurst [mailto:nj...@nj...]
> Sent: 05 February 2011 09:51
> To: A.J...@br...
> Cc: Engelen, J.B.C. (Johan); lib...@li...
> Subject: Re: [Lib2geom-devel] SBasis questions
> 
> On Sat, Feb 05, 2011 at 07:59:17AM +0000, A.J...@br...
> wrote:
> > Dear all,
> > On Fri, 2011-02-04 at 22:42 +0100, J.B...@ew...
> wrote:
> > > Chiming in quickly about this orphan directory idea. I think it is
> a
> > > very good idea! :-) Move all files that are no longer directly
used
> into
> > > such a directory. This makes 2geom more accessible for new users.
> > Rather than an orphan directory, and requiring calling code to be
> > modified, would it make more sense to simply guard the code with an
> > ifdef.  For example
> >
> > #ifdef USE_ORPHAN_CODE
> > ...
> > #endif
> >
> > Then it's not necessary to modify calling code but only to add a
> > -DUSE_ORPHAN_CODE to a build.
> >
> > This seems neater to me than (a) changing any existing calling code,
> and
> > (b) re-changing future calling code when the functions become
> > unorphaned?
> 
> That's a good suggestion, but the main reason for the orphan directory
> was to reduce the amount of dead code in the library proper.  Moving
> files isn't hard, and makes it clear what's important and what's not.

I am going to move some of the files that are excluded from the build
(by CmakeLists.txt) to the new directory "orphan code".
If anybody wants to start using the code again, it should be moved from
orphan code to the normal 2geom dir. Since there is no code calling it,
no need to change it. If there is code *outside* 2geom that is using the
'orphan' files, I hope those programmers won't be too mad at me for
moving the files to a different place. At least it will show them that
that code is probably no longer maintained, and it could break any
moment (since it is not included in 2geom building).

Ciao,
  Johan

Re: [Lib2geom-devel] SBasis questions

[Nathan H. <nj...@nj...>]

On Sat, Feb 05, 2011 at 07:59:17AM +0000, A.J...@br... wrote:
> Dear all,
> On Fri, 2011-02-04 at 22:42 +0100, J.B...@ew... wrote:
> > Chiming in quickly about this orphan directory idea. I think it is a
> > very good idea! :-) Move all files that are no longer directly used into
> > such a directory. This makes 2geom more accessible for new users.
> Rather than an orphan directory, and requiring calling code to be
> modified, would it make more sense to simply guard the code with an
> ifdef.  For example
> 
> #ifdef USE_ORPHAN_CODE
> ...
> #endif
> 
> Then it's not necessary to modify calling code but only to add a
> -DUSE_ORPHAN_CODE to a build.
> 
> This seems neater to me than (a) changing any existing calling code, and
> (b) re-changing future calling code when the functions become
> unorphaned?

That's a good suggestion, but the main reason for the orphan directory
was to reduce the amount of dead code in the library proper.  Moving
files isn't hard, and makes it clear what's important and what's not.

njh

Re: [Lib2geom-devel] SBasis questions

[<A.J...@br...>]

Dear all,
On Fri, 2011-02-04 at 22:42 +0100, J.B...@ew... wrote:
> Chiming in quickly about this orphan directory idea. I think it is a
> very good idea! :-) Move all files that are no longer directly used into
> such a directory. This makes 2geom more accessible for new users.
Rather than an orphan directory, and requiring calling code to be
modified, would it make more sense to simply guard the code with an
ifdef.  For example

#ifdef USE_ORPHAN_CODE
...
#endif

Then it's not necessary to modify calling code but only to add a
-DUSE_ORPHAN_CODE to a build.

This seems neater to me than (a) changing any existing calling code, and
(b) re-changing future calling code when the functions become
unorphaned?
-- 
Aidan


___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________

Re: [Lib2geom-devel] SBasis questions

[<J.B...@ew...>]

> -----Original Message-----
> From: Nathan Hurst [mailto:nj...@nj...]
> Sent: 04 February 2011 02:36
> To: Krzysztof Kosi??ski
> Cc: lib2geom-devel
> Subject: Re: [Lib2geom-devel] SBasis questions
> 
> On Fri, Feb 04, 2011 at 02:00:27AM +0100, Krzysztof Kosi??ski wrote:
> > Thanks for the quick answer.
> >
> > One more question: the tree contains the files "sbasisN.h" and
> > "sbasis-of.h", and similar ones for Linear. linearN.h looks like an
> > attempt at a multi-dimensional linearly interpolated function, and
> > linear-of.h like an attempt at allowing a diferent calculation type
> > than double. Are they used anywhere or are planned to be used, or is
> > it safe to remove them?
> 
> They were used for some experiments, and I belive are correct
> implementations.  They lack convincing toys, so I think rather than
> deleting, can you move them into an orphan directory?

Chiming in quickly about this orphan directory idea. I think it is a
very good idea! :-) Move all files that are no longer directly used into
such a directory. This makes 2geom more accessible for new users.

Cheers,
  Johan

Re: [Lib2geom-devel] SBasis questions

[Nathan H. <nj...@nj...>]

On Fri, Feb 04, 2011 at 02:00:27AM +0100, Krzysztof Kosi??ski wrote:
> Thanks for the quick answer.
> 
> One more question: the tree contains the files "sbasisN.h" and
> "sbasis-of.h", and similar ones for Linear. linearN.h looks like an
> attempt at a multi-dimensional linearly interpolated function, and
> linear-of.h like an attempt at allowing a diferent calculation type
> than double. Are they used anywhere or are planned to be used, or is
> it safe to remove them?

They were used for some experiments, and I belive are correct
implementations.  They lack convincing toys, so I think rather than
deleting, can you move them into an orphan directory?

njh

Re: [Lib2geom-devel] SBasis questions

[Krzysztof K. <twe...@gm...>]

Thanks for the quick answer.

One more question: the tree contains the files "sbasisN.h" and
"sbasis-of.h", and similar ones for Linear. linearN.h looks like an
attempt at a multi-dimensional linearly interpolated function, and
linear-of.h like an attempt at allowing a diferent calculation type
than double. Are they used anywhere or are planned to be used, or is
it safe to remove them?

Regards, Krzysztof

Re: [Lib2geom-devel] SBasis questions

[Nathan H. <nj...@nj...>]

On Fri, Feb 04, 2011 at 01:10:36AM +0100, Krzysztof Kosi??ski wrote:
> Hello
> 
> I'm inspecting the code for SBasis in order to clean it up and write
> some docs, and I have some questions.
> 
> 1. The paper on which SBasis is based (J. Sanchez-Reyes 1997) defines
> a power basis for odd degrees, and a modification for even degrees
> that uses an additional polynomial which is "split into two" when
> expanding the basis. It looks like our SBasis implementation defines
> odd degrees only, because I see nothing in valueAt that would take
> care of this extra polynomial. Is that correct?

Yes, I felt it was an unnecessary complication to save a few
multiplies and bytes here and there.

> 2. It looks like the vector interface is only a backwards
> compatibility mechanism and should be replaced by higher level
> methods. Is that correct?

Correct.

njh

[Lib2geom-devel] SBasis questions

[Krzysztof K. <twe...@gm...>]

Hello

I'm inspecting the code for SBasis in order to clean it up and write
some docs, and I have some questions.

1. The paper on which SBasis is based (J. Sanchez-Reyes 1997) defines
a power basis for odd degrees, and a modification for even degrees
that uses an additional polynomial which is "split into two" when
expanding the basis. It looks like our SBasis implementation defines
odd degrees only, because I see nothing in valueAt that would take
care of this extra polynomial. Is that correct?
2. It looks like the vector interface is only a backwards
compatibility mechanism and should be replaced by higher level
methods. Is that correct?

Regards, Krzysztof

Re: [Lib2geom-devel] Updated 2geom -- what changed?

[Josh A. <sc...@gm...>]

I added the missing files to inkscape trunk.

Cheers,
Josh

On Wed, Feb 2, 2011 at 1:50 PM, Josh Andler <sc...@gm...> wrote:
> Johan,
>
> It appears that the affine files were not added as a part of the commit.
>
> In file included from arc-context.cpp:26:0:
> display/sp-canvas.h:38:26: fatal error: 2geom/affine.h: No such file
> or directory
>
> Cheers,
> Josh
>
> On Wed, Feb 2, 2011 at 1:26 PM,  <J.B...@ew...> wrote:
>> Hi all,
>>
>> I just updated our copy of lib2geom to the latest trunk version (bzr
>> 10025). This greatly helps in improving Inkscape and lib2geom together.
>>
>> What changed in lib2geom since the last time we updated? Quite an
>> important name change has happened: Geom::Matrix is now called
>> Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs
>> were fixed (but were backported to Inkscape often too), and there are
>> some other name changes. See the list below.
>>
>> I have not done extensive tests, Inkscape seems to build fine, runs ok,
>> and what I tested (spiro LPE) works fine too. If there are any troubles,
>> let me know.
>>
>> Cheers,
>>  Johan
>>
>> _______________________________________________________________________
>> Relevant changes to lib2geom since last update:
>>
>> Geom::Matrix --> Geom::Affine
>> <2geom/matrix.h> --> <2geom/affine.h>
>>
>> Geom::Interval::extendTo --> expandTo
>>
>> Geom::Line::setBy2Points --> setPoints
>>
>> Geom::Line::origin(Geom::Point) --> setOrigin
>> Geom::Line::versor(Geom::Point) --> setVersor
>>
>>
>> Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation
>>
>> Geom::EllipticalArc::rotation_angle --> rotationAngle
>> Geom::EllipticalArc::large_arc_flag --> largeArc
>> Geom::EllipticalArc::sweep_flag --> sweep
>> _______________________________________________________________________
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Lib2geom-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>
>

Re: [Lib2geom-devel] Updated 2geom -- what changed?

[Josh A. <sc...@gm...>]

Johan,

It appears that the affine files were not added as a part of the commit.

In file included from arc-context.cpp:26:0:
display/sp-canvas.h:38:26: fatal error: 2geom/affine.h: No such file
or directory

Cheers,
Josh

On Wed, Feb 2, 2011 at 1:26 PM,  <J.B...@ew...> wrote:
> Hi all,
>
> I just updated our copy of lib2geom to the latest trunk version (bzr
> 10025). This greatly helps in improving Inkscape and lib2geom together.
>
> What changed in lib2geom since the last time we updated? Quite an
> important name change has happened: Geom::Matrix is now called
> Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs
> were fixed (but were backported to Inkscape often too), and there are
> some other name changes. See the list below.
>
> I have not done extensive tests, Inkscape seems to build fine, runs ok,
> and what I tested (spiro LPE) works fine too. If there are any troubles,
> let me know.
>
> Cheers,
>  Johan
>
> _______________________________________________________________________
> Relevant changes to lib2geom since last update:
>
> Geom::Matrix --> Geom::Affine
> <2geom/matrix.h> --> <2geom/affine.h>
>
> Geom::Interval::extendTo --> expandTo
>
> Geom::Line::setBy2Points --> setPoints
>
> Geom::Line::origin(Geom::Point) --> setOrigin
> Geom::Line::versor(Geom::Point) --> setVersor
>
>
> Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation
>
> Geom::EllipticalArc::rotation_angle --> rotationAngle
> Geom::EllipticalArc::large_arc_flag --> largeArc
> Geom::EllipticalArc::sweep_flag --> sweep
> _______________________________________________________________________
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>

[Lib2geom-devel] Updated 2geom -- what changed?

[<J.B...@ew...>]

Hi all,

I just updated our copy of lib2geom to the latest trunk version (bzr
10025). This greatly helps in improving Inkscape and lib2geom together. 

What changed in lib2geom since the last time we updated? Quite an
important name change has happened: Geom::Matrix is now called
Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs
were fixed (but were backported to Inkscape often too), and there are
some other name changes. See the list below.

I have not done extensive tests, Inkscape seems to build fine, runs ok,
and what I tested (spiro LPE) works fine too. If there are any troubles,
let me know.

Cheers,
  Johan

_______________________________________________________________________
Relevant changes to lib2geom since last update:

Geom::Matrix --> Geom::Affine
<2geom/matrix.h> --> <2geom/affine.h>

Geom::Interval::extendTo --> expandTo

Geom::Line::setBy2Points --> setPoints

Geom::Line::origin(Geom::Point) --> setOrigin
Geom::Line::versor(Geom::Point) --> setVersor


Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation

Geom::EllipticalArc::rotation_angle --> rotationAngle
Geom::EllipticalArc::large_arc_flag --> largeArc
Geom::EllipticalArc::sweep_flag --> sweep
_______________________________________________________________________

Re: [Lib2geom-devel] Upgrading Inkscape's 2geom

[<J.B...@ew...>]

> -----Original Message-----
> From: Krzysztof Kosiński [mailto:twe...@gm...]
> Sent: 01 February 2011 23:35
> To: Engelen, J.B.C. (Johan)
> Cc: ink...@li...; lib2geom-
> de...@li...
> Subject: Re: [Lib2geom-devel] Upgrading Inkscape's 2geom
> 
> 2011/2/1  <J.B...@ew...>:
> > Eek! I already started the work... it turns out to be not that much
> work though.
> > Do you mean that you removed non-2geom stuff in favor of 2geom, and
> that when I do the conversion now, that that would give you extra work
> in your code?  Would it be OK if I send you the search&replace strings
> to get it working?
> > Just these two replacements:
> > Geom::Matrix --> Geom::Affine
> > <2geom/matrix.h> --> <2geom/affine.h>
> > gives almost a working build. Some function names changed, but those
> functions are rarely used; so fixing those is not too much work.
> 
> If you started the work already, feel free to continue - it shouldn't
> take too long to update my branch. I don't remember using any advanced
> 2Geom features, so replacing Matrix with Affine should fix 95% of
> code. I was really thinking about further 2Geom-ification - that would
> benefit from doing it in the Cairo branch.

Done!

  -Johan

Re: [Lib2geom-devel] [Inkscape-devel] Upgrading Inkscape's 2geom

[Krzysztof K. <twe...@gm...>]

2011/2/2 Jon Cruz <jo...@jo...>:
> The first warning was that until an even release is made with the feature we want, it is *technically* ok for them to change or remove any APIs up until the last minute.

I don't want to argue with your premises, as I also agree we should
wait some time before releasing a version of Inkscape that depends on
Cairo 1.12, but I want to make two clarifications.
1. We do not use any API newly introduced in 1.11. We just need it for
a substantial rendering bugfix.
2. The development version can start depending on 1.12 before that
version of Cairo makes its way into distros. Installing a newer
version of a library is very easy, and you only need it to improve the
rendering quality, not to make Inkscape work at all. Developers not
focusing on the rendering subsystem should be able to work with 1.10.

> The main need for compatibility is those with a business-oriented or LTS approach. By keeping more compatible with such stable releases, we can target professional use of Inkscape and move away from the "just a toy" trap. We get *many* requests from those who want to either install an additional newer Inkscape version or to grab a newer PPA or such of an updated Inkscape. (and keep in mind that we had made changes to allow for easy parallel installation of multiple Inkscape versions).

My answer would be: if you have an LTS installation, use the LTS
version of Inkscape. Library compatibility should be taken into
account, but holding up major features because someone might want to
use an old distro is just counter-productive.

The PPA route looks like the best compromise, and it's working well
for other projects.

Regards, Krzysztof

Re: [Lib2geom-devel] [Inkscape-devel] Upgrading Inkscape's 2geom

[Josh A. <sc...@gm...>]

On Wed, Feb 2, 2011 at 2:11 AM, Jon Cruz <jo...@jo...> wrote:
>
> On Feb 2, 2011, at 1:45 AM, Josh Andler wrote:
>
>> Agreed about targeting professionals... however wrt a PPA, if we know
>> of a newer cairo to not have any (known) regressions, we can offer
>> those too via "the" PPA or Suse's build service. I think we can offer
>> the necessary dependencies just as many PPAs do. (of course, this
>> involves us actually setting up an official PPA)
>
> One big gotcha is that in general a PPA won't install in parallel, but instead overwrites the current version. For an app this is not as big of an issue, but stomping over a system library can have some 'interesting' effects for users and other apps.

If we're so inclined, we can avoid stomping over system libraries
(probably not fun for figuring out packaging). However, I wilfully
have packages stomped over on a semi-regular basis and it tends to fix
more bugs than it causes. I'm not saying it's good practice... but it
tends to not be as negative. For the record, this has happened for me
w/ either cairo and/or pixman on numerous occasions and been pretty
successful.

Cheers,
Josh

Re: [Lib2geom-devel] [Inkscape-devel] Upgrading Inkscape's 2geom

[Jon C. <jo...@jo...>]

On Feb 2, 2011, at 1:45 AM, Josh Andler wrote:

> Agreed about targeting professionals... however wrt a PPA, if we know
> of a newer cairo to not have any (known) regressions, we can offer
> those too via "the" PPA or Suse's build service. I think we can offer
> the necessary dependencies just as many PPAs do. (of course, this
> involves us actually setting up an official PPA)

One big gotcha is that in general a PPA won't install in parallel, but instead overwrites the current version. For an app this is not as big of an issue, but stomping over a system library can have some 'interesting' effects for users and other apps.

Re: [Lib2geom-devel] [Inkscape-devel] Upgrading Inkscape's 2geom

[Josh A. <sc...@gm...>]

On Wed, Feb 2, 2011 at 1:01 AM, Jon Cruz <jo...@jo...> wrote:
>
> On Feb 1, 2011, at 1:29 PM, <J.B...@ew...> wrote:
>
>>>
>>> The Cairo version should be mostly usable right now, but requires
>>> using a development release of Cairo that fixes some precision
>>> problems with gradients.
>>
>> How long will it take for this to be fixed?
>>
>> Although I do not want to give you extra headaches, I really want to get our copy of 2geom updated asap. It's been way too long since we did the last update.
>
> Well, it turns out I was talking with the Cairo guys this past week at linux.conf.au on this very subject.
>
> The first warning was that until an even release is made with the feature we want, it is *technically* ok for them to change or remove any APIs up until the last minute. So we shouldn't really start using that in our main code until they have an initial even number release with the feature/API we want.

Agreed about the even numbered release.

> Secondly, and also more important according to them, is that we want to wait until distros have time to assess that release, bring it in, and then make a release themselves. For some distros we can go with a simultaneous targeting, but for others we will most likely want to keep a fair window of compatibility.

This I am less worried about. I think that if they are scrutinizing a
new cairo release, they're scrutinizing everything else (including a
new Inkscape release).

> The main need for compatibility is those with a business-oriented or LTS approach. By keeping more compatible with such stable releases, we can target professional use of Inkscape and move away from the "just a toy" trap. We get *many* requests from those who want to either install an additional newer Inkscape version or to grab a newer PPA or such of an updated Inkscape. (and keep in mind that we had made changes to allow for easy parallel installation of multiple Inkscape versions).

Agreed about targeting professionals... however wrt a PPA, if we know
of a newer cairo to not have any (known) regressions, we can offer
those too via "the" PPA or Suse's build service. I think we can offer
the necessary dependencies just as many PPAs do. (of course, this
involves us actually setting up an official PPA)

Cheers,
Josh

P.S. For professional use, I still find a 10 year old copy of
Illustrator to be more friendly... Resources never get out of hand by
comparison to a few minutes of use of Inkscape (and yes, that's with
me cranking up the undo history preferences in AI).

Re: [Lib2geom-devel] [Inkscape-devel] Upgrading Inkscape's 2geom

[Jon C. <jo...@jo...>]

On Feb 1, 2011, at 1:29 PM, <J.B...@ew...> wrote:

>> 
>> The Cairo version should be mostly usable right now, but requires
>> using a development release of Cairo that fixes some precision
>> problems with gradients.
> 
> How long will it take for this to be fixed?
> 
> Although I do not want to give you extra headaches, I really want to get our copy of 2geom updated asap. It's been way too long since we did the last update.

Well, it turns out I was talking with the Cairo guys this past week at linux.conf.au on this very subject.

The first warning was that until an even release is made with the feature we want, it is *technically* ok for them to change or remove any APIs up until the last minute. So we shouldn't really start using that in our main code until they have an initial even number release with the feature/API we want.

Secondly, and also more important according to them, is that we want to wait until distros have time to assess that release, bring it in, and then make a release themselves. For some distros we can go with a simultaneous targeting, but for others we will most likely want to keep a fair window of compatibility.

The main need for compatibility is those with a business-oriented or LTS approach. By keeping more compatible with such stable releases, we can target professional use of Inkscape and move away from the "just a toy" trap. We get *many* requests from those who want to either install an additional newer Inkscape version or to grab a newer PPA or such of an updated Inkscape. (and keep in mind that we had made changes to allow for easy parallel installation of multiple Inkscape versions).

 
Bottom line is that I think a switch to the newer lib2geom will bring in a lot without causing many breaking changes.

Re: [Lib2geom-devel] Upgrading Inkscape's 2geom

[Krzysztof K. <twe...@gm...>]

2011/2/1  <J.B...@ew...>:
> Eek! I already started the work... it turns out to be not that much work though.
> Do you mean that you removed non-2geom stuff in favor of 2geom, and that when I do the conversion now, that that would give you extra work in your code?  Would it be OK if I send you the search&replace strings to get it working?
> Just these two replacements:
> Geom::Matrix --> Geom::Affine
> <2geom/matrix.h> --> <2geom/affine.h>
> gives almost a working build. Some function names changed, but those functions are rarely used; so fixing those is not too much work.

If you started the work already, feel free to continue - it shouldn't
take too long to update my branch. I don't remember using any advanced
2Geom features, so replacing Matrix with Affine should fix 95% of
code. I was really thinking about further 2Geom-ification - that would
benefit from doing it in the Cairo branch.

Cairo 1.12 is still probably a few months away.

By the way, Cairo 1.10 doesn't crash the Cairo branch, prevent it from
compiling anything, it just misrenders some gradients. You can use
1.10, but the rendering accuracy will not be acceptable for serious
use.

Regards, Krzysztof

Re: [Lib2geom-devel] Upgrading Inkscape's 2geom

[Josh A. <sc...@gm...>]

On Tue, Feb 1, 2011 at 1:30 PM,  <J.B...@ew...> wrote:
>> -----Original Message-----
>> From: Engelen, J.B.C. (Johan)
>> Sent: 01 February 2011 22:30
>> To: 'Krzysztof Kosiński'
>> Cc: ink...@li...; lib2geom-
>> de...@li...
>> Subject: RE: [Lib2geom-devel] Upgrading Inkscape's 2geom
>>
>> > -----Original Message-----
>> > From: Krzysztof Kosiński [mailto:twe...@gm...]
>> > Sent: 01 February 2011 21:49
>> > To: Engelen, J.B.C. (Johan)
>> > Cc: ink...@li...; lib2geom-
>> > de...@li...
>> > Subject: Re: [Lib2geom-devel] Upgrading Inkscape's 2geom
>> >
>> > The Cairo version should be mostly usable right now, but requires
>> > using a development release of Cairo that fixes some precision
>> > problems with gradients.
>>
>> How long will it take for this to be fixed?
>
> I meant: how long will it take for the fix to be released in a stable (read: usable by Inkscape) version?

Difficult issue... Win32 we bundle the libs, so as soon as it's
released we can update the libs. It should theoretically be in the
next round of distro releases if they're (cairo folks) aiming for a 6
month cycle. If I'm not mistaken, Macports tends to keep things
reasonably current. So, for 2/3 platforms it should be good in short
order... but the Linux world varies quite a bit given LTS & Enterprise
users, people who wait for things to be out for a while before
updating, etc. The main thing though is that LTS users also wouldn't
expect the latest and greatest version of Inkscape for their installs
unless they compile themselves, in which case I think it's basically a
"tough luck" situation. For them, we have the bug fixed 0.48.x series
which is stable, just how they like things. ;)

Cheers,
Josh