Menu
▾
▴
lib2geom-devel — development discussion
You can subscribe to this list here.
| 2007 |
Jan
(2) |
Feb
(3) |
Mar
(4) |
Apr
(27) |
May
(5) |
Jun
|
Jul
(14) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(19) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(4) |
Apr
(28) |
May
(77) |
Jun
(79) |
Jul
(112) |
Aug
(36) |
Sep
(33) |
Oct
(19) |
Nov
(9) |
Dec
(11) |
| 2009 |
Jan
|
Feb
|
Mar
(12) |
Apr
(11) |
May
(13) |
Jun
(23) |
Jul
(5) |
Aug
(25) |
Sep
(9) |
Oct
(22) |
Nov
(16) |
Dec
(5) |
| 2010 |
Jan
(23) |
Feb
(12) |
Mar
(5) |
Apr
(29) |
May
(4) |
Jun
(9) |
Jul
(22) |
Aug
(2) |
Sep
(10) |
Oct
(6) |
Nov
(8) |
Dec
|
| 2011 |
Jan
(2) |
Feb
(44) |
Mar
|
Apr
(4) |
May
|
Jun
(9) |
Jul
(5) |
Aug
(4) |
Sep
(7) |
Oct
|
Nov
|
Dec
(10) |
| 2012 |
Jan
(16) |
Feb
(8) |
Mar
(9) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(6) |
Aug
(10) |
Sep
(48) |
Oct
(6) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(19) |
Sep
(3) |
Oct
(5) |
Nov
(35) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(4) |
Apr
(12) |
May
(6) |
Jun
(16) |
Jul
(25) |
Aug
(16) |
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
| 2015 |
Jan
(3) |
Feb
(1) |
Mar
(21) |
Apr
(10) |
May
(6) |
Jun
(3) |
Jul
(2) |
Aug
(4) |
Sep
(4) |
Oct
|
Nov
(2) |
Dec
|
| 2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Diederik v. L. <ma...@di...> - 2008-05-06 06:30:05
|
Sorry, I only intended to send a single copy of my mail to lib2geom-dev :-( Diederik Op Di, 6 mei, 2008 08:15, schreef Diederik van Lierop: > Hi, > > Maybe it's just me doing something wrong, but I cannot get an intersection > with the _closing_ segment of a rectangle. The first three segments > between the four points of the rectangle behave as expected and do > intersect nicely, but it looks like the closing segments is discarded when > using the SimpleCrosser(). > > Is this by design or a bug, or am I missing something? > > This behaviour introduces a bug in Inkscape's snapping mechanism. For a > constrained snap, I need to find an intersection of a linesegment (in the > direction of the constrained handle movement) with an arbitrary path, but > this doesn't work for the closing segment. > > Regards, > > Diederik > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Inkscape-devel mailing list > Ink...@li... > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > |
|
From: Diederik v. L. <ma...@di...> - 2008-05-06 06:17:54
|
Hi, Maybe it's just me doing something wrong, but I cannot get an intersection with the _closing_ segment of a rectangle. The first three segments between the four points of the rectangle behave as expected and do intersect nicely, but it looks like the closing segments is discarded when using the SimpleCrosser(). Is this by design or a bug, or am I missing something? This behaviour introduces a bug in Inkscape's snapping mechanism. For a constrained snap, I need to find an intersection of a linesegment (in the direction of the constrained handle movement) with an arbitrary path, but this doesn't work for the closing segment. Regards, Diederik |
|
From: Diederik v. L. <ma...@di...> - 2008-05-06 06:15:54
|
Hi, Maybe it's just me doing something wrong, but I cannot get an intersection with the _closing_ segment of a rectangle. The first three segments between the four points of the rectangle behave as expected and do intersect nicely, but it looks like the closing segments is discarded when using the SimpleCrosser(). Is this by design or a bug, or am I missing something? This behaviour introduces a bug in Inkscape's snapping mechanism. For a constrained snap, I need to find an intersection of a linesegment (in the direction of the constrained handle movement) with an arbitrary path, but this doesn't work for the closing segment. Regards, Diederik |
|
From: Marco <mrc...@gm...> - 2008-04-29 11:38:52
|
I turned assertions into calls to the throwRangeError macro. I committed the changes to both lib2geom and inkscape. Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Marco <mrc...@gm...> - 2008-04-29 10:47:49
|
On Tue, 29 Apr 2008 02:46:41 +0200, Bryce Harrington <br...@ca...> wrote: > On Mon, Apr 28, 2008 at 04:42:34PM +0200, Marco wrote: >> >> I'm developing lib2geom and sometimes I need to update >> the /2geom source code under inkscape, too. >> >> Until now, Johan Engelen has always kindly synchronized >> the source code, but if I could have an inkscape >> svn write-enabled account this would speed up things. >> My sourceforge user name is: mcecchetti >> >> Kind Regards, >> Marco Cecchetti > > Welcome aboard Marco, and I look forward to seeing the 2geom integration > move forward, and I very much look forward to seeing 2geom officially > released. > > Bryce Thanks! I look forward for such goals, too. :-) I and Nathan will work hard this summer to make 2geom even more powerful and reliable. Kind Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Bryce H. <br...@ca...> - 2008-04-29 00:46:52
|
On Mon, Apr 28, 2008 at 04:42:34PM +0200, Marco wrote: > > I'm developing lib2geom and sometimes I need to update > the /2geom source code under inkscape, too. > > Until now, Johan Engelen has always kindly synchronized > the source code, but if I could have an inkscape > svn write-enabled account this would speed up things. > My sourceforge user name is: mcecchetti > > Kind Regards, > Marco Cecchetti Welcome aboard Marco, and I look forward to seeing the 2geom integration move forward, and I very much look forward to seeing 2geom officially released. Bryce |
|
From: Marco <mrc...@gm...> - 2008-04-28 15:02:59
|
I'm developing lib2geom and sometimes I need to update the /2geom source code under inkscape, too. Until now, Johan Engelen has always kindly synchronized the source code, but if I could have an inkscape svn write-enabled account this would speed up things. My sourceforge user name is: mcecchetti Kind Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Marco <mrc...@gm...> - 2008-04-28 13:24:58
|
On Mon, 28 Apr 2008 15:04:44 +0200, <J.B...@ew...> wrote: >> -----Original Message----- >> From: Marco [mailto:mrc...@gm...] >> Sent: maandag 28 april 2008 14:08 >> To: Engelen, J.B.C. (Johan); bul...@gm...; me...@ry... >> Cc: ink...@li...; >> lib...@li... >> Subject: Re: [Inkscape-devel] [Lib2geom-devel] >> newSVGEllipticalArcimplementation merged intopath.h >> >> On Mon, 28 Apr 2008 13:16:19 +0200, >> <J.B...@ew...> wrote: >> >> >> > However, I think it is best if we add some sort of debug >> >> flag so that >> >> > people can choose between throwing an exception or doing >> an assert >> >> > (crash). >> >> >> >> Do you mean a simple #ifdef DEBUG or an ad-hoc flag ? >> >> Something like ELLIPTICAL_ARC_DEBUG ? >> > >> > I meant a global flag, that chooses how to expand the >> exception throw >> > macros; not just for the elliptical arc implementation. So >> 2geom either >> > throws exceptions or does asserts. >> > >> > #define LIB2GEOM_EXCEPTIONS // define to have 2geom throw >> exceptions >> > instead of asserts >> >> That's ok, however I was thinking that it would be better to >> have the conditional defined code in just one place. >> So what do you think of defining the throwXxxxYyyy macros in >> the following way: > > Exactly what I meant :-) Ah ok. Sorry, I incurred in an "english" misunderstanding. Btw, what should I do to get an inkscape svn account (write-enabled) so I can commit the modified files directly ? Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: <J.B...@ew...> - 2008-04-28 13:05:56
|
> -----Original Message----- > From: Marco [mailto:mrc...@gm...] > Sent: maandag 28 april 2008 14:08 > To: Engelen, J.B.C. (Johan); bul...@gm...; me...@ry... > Cc: ink...@li...; > lib...@li... > Subject: Re: [Inkscape-devel] [Lib2geom-devel] > newSVGEllipticalArcimplementation merged intopath.h > > On Mon, 28 Apr 2008 13:16:19 +0200, > <J.B...@ew...> wrote: > > >> > However, I think it is best if we add some sort of debug > >> flag so that > >> > people can choose between throwing an exception or doing > an assert > >> > (crash). > >> > >> Do you mean a simple #ifdef DEBUG or an ad-hoc flag ? > >> Something like ELLIPTICAL_ARC_DEBUG ? > > > > I meant a global flag, that chooses how to expand the > exception throw > > macros; not just for the elliptical arc implementation. So > 2geom either > > throws exceptions or does asserts. > > > > #define LIB2GEOM_EXCEPTIONS // define to have 2geom throw > exceptions > > instead of asserts > > That's ok, however I was thinking that it would be better to > have the conditional defined code in just one place. > So what do you think of defining the throwXxxxYyyy macros in > the following way: Exactly what I meant :-) |
|
From: Marco <mrc...@gm...> - 2008-04-28 12:34:02
|
On Mon, 28 Apr 2008 14:07:46 +0200, Marco <mrc...@gm...> wrote:
> #ifdef LIB2GEOM_EXCEPTIONS
> # define throwException( cond, message ) \
> if ( (cond) ) throw(Geom::Exception(message, __FILE__,
> __LINE__))
> # define throwRangeError( cond, message ) \
> if ( (cond) ) throw(RangeError(message, __FILE__, __LINE__))
> .
> .
> .
> #else
> # define throwException( cond, message ) \
> if( (cond) ) std::cerr << "lib2geom Error: " << message << std::endl; \
> assert( (cond) )
> # define throwRangeError( cond, message ) \
> if( (cond) ) std::cerr << "lib2geom RangeError: " << message <<
> std::endl; \
> assert( (cond) )
> .
> .
> .
> #endif // LIB2GEOM_EXCEPTIONS
>
>
>
> Marco
>
Ops, I forgot some logical negation :
#ifdef LIB2GEOM_EXCEPTIONS
# define throwException( cond, message ) \
if ( (cond) ) throw(Geom::Exception(message, __FILE__, __LINE__))
# define throwRangeError( cond, message ) \
if ( (cond) ) throw(RangeError(message, __FILE__, __LINE__))
.
.
.
#else
# define throwException( cond, message ) \
if( (cond) ) std::cerr << "lib2geom Error: " << message << std::endl; \
assert( !(cond) )
# define throwRangeError( cond, message ) \
if( (cond) ) std::cerr << "lib2geom RangeError: " << message <<
std::endl; \
assert( !(cond) )
.
.
.
#endif // LIB2GEOM_EXCEPTIONS
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
From: Marco <mrc...@gm...> - 2008-04-28 12:07:55
|
On Mon, 28 Apr 2008 13:16:19 +0200, <J.B...@ew...> wrote:
>> > However, I think it is best if we add some sort of debug
>> flag so that
>> > people can choose between throwing an exception or doing an assert
>> > (crash).
>>
>> Do you mean a simple #ifdef DEBUG or an ad-hoc flag ?
>> Something like ELLIPTICAL_ARC_DEBUG ?
>
> I meant a global flag, that chooses how to expand the exception throw
> macros; not just for the elliptical arc implementation. So 2geom either
> throws exceptions or does asserts.
>
> #define LIB2GEOM_EXCEPTIONS // define to have 2geom throw exceptions
> instead of asserts
That's ok, however I was thinking that it would be better to have
the conditional defined code in just one place.
So what do you think of defining the throwXxxxYyyy macros
in the following way:
#ifdef LIB2GEOM_EXCEPTIONS
# define throwException( cond, message ) \
if ( (cond) ) throw(Geom::Exception(message, __FILE__, __LINE__))
# define throwRangeError( cond, message ) \
if ( (cond) ) throw(RangeError(message, __FILE__, __LINE__))
.
.
.
#else
# define throwException( cond, message ) \
if( (cond) ) std::cerr << "lib2geom Error: " << message << std::endl; \
assert( (cond) )
# define throwRangeError( cond, message ) \
if( (cond) ) std::cerr << "lib2geom RangeError: " << message <<
std::endl; \
assert( (cond) )
.
.
.
#endif // LIB2GEOM_EXCEPTIONS
Marco
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
From: <J.B...@ew...> - 2008-04-28 11:16:53
|
> > However, I think it is best if we add some sort of debug > flag so that > > people can choose between throwing an exception or doing an assert > > (crash). > > Do you mean a simple #ifdef DEBUG or an ad-hoc flag ? > Something like ELLIPTICAL_ARC_DEBUG ? I meant a global flag, that chooses how to expand the exception throw macros; not just for the elliptical arc implementation. So 2geom either throws exceptions or does asserts. #define LIB2GEOM_EXCEPTIONS // define to have 2geom throw exceptions instead of asserts |
|
From: Marco <mrc...@gm...> - 2008-04-28 10:43:26
|
On Mon, 28 Apr 2008 12:14:13 +0200, <J.B...@ew...> wrote: >> -----Original Message----- >> From: Marco [mailto:mrc...@gm...] >> Sent: maandag 28 april 2008 12:07 >> To: bulia byak; Engelen, J.B.C. (Johan); MenTaLguY >> Cc: ink...@li...; >> lib...@li... >> Subject: Re: [Inkscape-devel] [Lib2geom-devel] >> newSVGEllipticalArcimplementation merged intopath.h >> >> On Mon, 28 Apr 2008 03:45:36 +0200, bulia byak >> <bul...@gm...> wrote: >> >> > On Sun, Apr 13, 2008 at 4:29 PM, >> <J.B...@ew...> wrote: >> >> I think right now I can remove an error message in >> Inkscape=>2geom >> >> conversion when a path contains an 'A' description. Can't remember >> >> exactly, but will check soon. Thanks!!! >> > >> > Before, pattern on path failed for ellipse pattern - now it >> crashes with: >> > >> > inkscape: 2geom/svg-elliptical-arc.cpp:128: void >> > Geom::SVGEllipticalArc::calculate_center_and_extreme_angles(): >> > Assertion `-1 < arg && arg < 1' failed. >> > >> > Emergency save activated! >> > >> >> This assertion is raised when the parameter passed to the >> SVGEllipticalArc constructor can't be used to create an >> elliptical arc. >> That is, given the x and y rays, the rotation angle and the >> initial and final points there is no ellipse that satisfies >> all together such constraints and so it's not possible to >> build an elliptical arc with the passed data. >> Would you like to manage such case by throwing an exception >> or by quietly setting a boolean flag that will have to be >> tested after each elliptical arc instantiation ? > > I think it's best when you change the assertion to throwing an exception > (see exception.h for some macros). I see, I'll use the RangeError. > However, I think it is best if we add some sort of debug flag so that > people can choose between throwing an exception or doing an assert > (crash). Do you mean a simple #ifdef DEBUG or an ad-hoc flag ? Something like ELLIPTICAL_ARC_DEBUG ? > Inkscape release should have exceptions, Inkscape devel should have > crashes. That way we won't stop thinking about fixing the bugs, and also > have a more stable release version. > I'll have a look and change the exception.h macros according to this, so > please use them :) > That's ok. Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: <J.B...@ew...> - 2008-04-28 10:14:50
|
> -----Original Message----- > From: Marco [mailto:mrc...@gm...] > Sent: maandag 28 april 2008 12:07 > To: bulia byak; Engelen, J.B.C. (Johan); MenTaLguY > Cc: ink...@li...; > lib...@li... > Subject: Re: [Inkscape-devel] [Lib2geom-devel] > newSVGEllipticalArcimplementation merged intopath.h > > On Mon, 28 Apr 2008 03:45:36 +0200, bulia byak > <bul...@gm...> wrote: > > > On Sun, Apr 13, 2008 at 4:29 PM, > <J.B...@ew...> wrote: > >> I think right now I can remove an error message in > Inkscape=>2geom > >> conversion when a path contains an 'A' description. Can't remember > >> exactly, but will check soon. Thanks!!! > > > > Before, pattern on path failed for ellipse pattern - now it > crashes with: > > > > inkscape: 2geom/svg-elliptical-arc.cpp:128: void > > Geom::SVGEllipticalArc::calculate_center_and_extreme_angles(): > > Assertion `-1 < arg && arg < 1' failed. > > > > Emergency save activated! > > > > This assertion is raised when the parameter passed to the > SVGEllipticalArc constructor can't be used to create an > elliptical arc. > That is, given the x and y rays, the rotation angle and the > initial and final points there is no ellipse that satisfies > all together such constraints and so it's not possible to > build an elliptical arc with the passed data. > Would you like to manage such case by throwing an exception > or by quietly setting a boolean flag that will have to be > tested after each elliptical arc instantiation ? I think it's best when you change the assertion to throwing an exception (see exception.h for some macros). However, I think it is best if we add some sort of debug flag so that people can choose between throwing an exception or doing an assert (crash). Inkscape release should have exceptions, Inkscape devel should have crashes. That way we won't stop thinking about fixing the bugs, and also have a more stable release version. I'll have a look and change the exception.h macros according to this, so please use them :) Kind regards, Johan |
|
From: Marco <mrc...@gm...> - 2008-04-28 10:06:47
|
On Mon, 28 Apr 2008 03:45:36 +0200, bulia byak <bul...@gm...> wrote: > On Sun, Apr 13, 2008 at 4:29 PM, <J.B...@ew...> wrote: >> I think right now I can remove an error message in Inkscape=>2geom >> conversion when a path contains an 'A' description. Can't remember >> exactly, but will check soon. Thanks!!! > > Before, pattern on path failed for ellipse pattern - now it crashes with: > > inkscape: 2geom/svg-elliptical-arc.cpp:128: void > Geom::SVGEllipticalArc::calculate_center_and_extreme_angles(): > Assertion `-1 < arg && arg < 1' failed. > > Emergency save activated! > This assertion is raised when the parameter passed to the SVGEllipticalArc constructor can't be used to create an elliptical arc. That is, given the x and y rays, the rotation angle and the initial and final points there is no ellipse that satisfies all together such constraints and so it's not possible to build an elliptical arc with the passed data. Would you like to manage such case by throwing an exception or by quietly setting a boolean flag that will have to be tested after each elliptical arc instantiation ? Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Marco <mrc...@gm...> - 2008-04-22 11:17:30
|
On Tue, 22 Apr 2008 10:04:16 +0200, <J.B...@ew...> wrote: > Hi all! > > I just heard the great news! Thanks for giving me this opportunity again! > Congratulations Felipe, Marco, Jasper and Max! Special note to Max and > Marco: since you do geometry things, I'd be happy to work more closely > with you if possible and desired :) To Jasper: is it okay if I bug you > about path tests? :) > Really excited by the project ideas that were accepted! Hi Johan! Congratulations to you as well! You can rely on my collaboration in your refactoring task! And the same is true for Max project, too. > skip > For the people that are afraid I will be messing up trunk badly: I first > intend to do changes in the way the code accesses the path data, then > make a test function for conversion to 2geom, then have both > representations in inkscape at the same time and constantly check > whether they are the same, etc. I intend to do small steps towards > completely going to 2geom, so I am more sure that it actually works and > did not introduce new bugs. > > Please let me know what you think of this. It sounds good for me. It seems to me that you have to take the right precautions on your mind, so you can commit into trunk directly. Cheers, Marco PS: have you a gmail account that you check for IM ? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Marco <mrc...@gm...> - 2008-04-21 21:14:41
|
On Mon, 21 Apr 2008 21:52:53 +0200, njh <nj...@nj...> wrote: > http://code.google.com/soc/2008/inkscape/about.html > > njh I'm very happy for the good news :-) I hope to achieve all goals I exposed in my proposal with the help of Nathan and the hints and suggestions from the inkscape community. Congratulations to all other accepted applicants. Kind Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: MenTaLguY <me...@ry...> - 2008-04-17 20:16:15
|
On Thu, 17 Apr 2008 11:16:51 +0200, J.B...@ew... wrote: > Hi all, > > Is it okay if I add "eol-style:native" property to all code files in SVN? > > This would help me a lot in keeping Inkscape's 2geom copy up-2-date. Please proceed. -mental |
|
From: njh <nj...@nj...> - 2008-04-17 16:55:59
|
Please do. I'm sick of typing 'y''y' everytime I load a 2geom file in emacs too, so if you can update the editor stuff at the bottom of each file to match inkscape, that'd be super! :) On Thu, 17 Apr 2008 J.B...@ew... wrote: > Hi all, > > Is it okay if I add "eol-style:native" property to all code files in SVN? > > This would help me a lot in keeping Inkscape's 2geom copy up-2-date. > > Thanks, > Johan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Lib2geom-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > |
|
From: <J.B...@ew...> - 2008-04-17 09:33:08
|
> -----Original Message-----
> From: njh [mailto:nj...@nj...]
> Sent: woensdag 16 april 2008 18:55
> To: Engelen, J.B.C. (Johan)
> Cc: jf....@gm...; lib...@li...
> Subject: Re: path::toPwSb for closed paths
>
> On Wed, 16 Apr 2008 J.B...@ew... wrote:
>
> > Hi all,
> >
> > Have a look at rev. 1175. I think I made a mistake there.
> Right now, the closing segment of a closed path is not added
> to pwd2. So LPEs do not function correctly with closed paths.
> > I can't remember why I did rev. 1175; it does not say which
> bug specifically it is supposed to fix.
> >
> > Do you guys think rev 1175 should be reverted?
>
> Are you referring to
> Index: src/path.h
> ===================================================================
> --- src/path.h (revision 1174)
> +++ src/path.h (working copy)
> @@ -492,7 +492,8 @@
> Piecewise<D2<SBasis> > ret;
> ret.push_cut(0);
> unsigned i = 1;
> - for(const_iterator it = begin(); it != end_default();
> ++it, i++) {
> + // ignore that path is closed or open. pw<d2<>> is always open.
> + for(const_iterator it = begin(); it != end(); ++it, i++) {
> ret.push(it->toSBasis(), i);
> }
> return ret;
>
> We have argued endlessly about the semantics of closed and
> open paths.
> Paths have a flag to say whether they are open or closed,
> whereas d2<pw> does not have that notion. This is because
> the correct behaviour when transforming a d2<pw> is not
> always clear wrt the closing segment. For example, the
> closing segment is always a line, but if we have a transform
> which does not preserve lines then should we transform that
> last line? I would argue yes in many cases. Thus, we should
> include the last line segment as a linear() in the d2.
>
> Looking at the code, I would say that
> - for(const_iterator it = begin(); it != end_default();
> ++it, i++) {
> is correct. I don't know why you made the change - there
> might be a bug elsewhere that this obscured (*gasp*).
I just changed it back. It fixes Inkscape's LPE bug.
Thanks,
Johan
|
|
From: <J.B...@ew...> - 2008-04-17 09:16:42
|
Hi all, Is it okay if I add "eol-style:native" property to all code files in SVN? This would help me a lot in keeping Inkscape's 2geom copy up-2-date. Thanks, Johan |
|
From: MenTaLguY <me...@ry...> - 2008-04-16 18:00:20
|
On Wed, 16 Apr 2008 11:39:51 +0200, Maximilian Albert <Anh...@gm...> wrote: > However, I have noticed that drawing operations are considerably slower > when 2geom is used. The ellipse tool with the new code always lags a bit > behind the mouse pointer. I also encountered this when working on my > simplistic "tech drawing circle LPE" a while ago. It's not particularly > annoying but clearly noticeable. Is this issue inherent? Or is it just > due to me using the data structures in the wrong way or calling the > "wrong" (i.e., computationally expensive) kinds of functions? Without looking at your code I can't rule out the former, but there are definitely some important optimizations which need to be made. Probably the most important optimization would be to make Path objects share data in a copy-on-write fasion -- at the moment, when you return a Path from a function, say, it has to copy the entire Path data structure each time. That adds up after a while. The most helpful thing would actually be if you could collect some profiling data, so we can see which code needs the most optimization right now. -mental |
|
From: njh <nj...@nj...> - 2008-04-16 16:55:09
|
On Wed, 16 Apr 2008 J.B...@ew... wrote:
> Hi all,
>
> Have a look at rev. 1175. I think I made a mistake there. Right now, the closing segment of a closed path is not added to pwd2. So LPEs do not function correctly with closed paths.
> I can't remember why I did rev. 1175; it does not say which bug specifically it is supposed to fix.
>
> Do you guys think rev 1175 should be reverted?
Are you referring to
Index: src/path.h
===================================================================
--- src/path.h (revision 1174)
+++ src/path.h (working copy)
@@ -492,7 +492,8 @@
Piecewise<D2<SBasis> > ret;
ret.push_cut(0);
unsigned i = 1;
- for(const_iterator it = begin(); it != end_default(); ++it, i++) {
+ // ignore that path is closed or open. pw<d2<>> is always open.
+ for(const_iterator it = begin(); it != end(); ++it, i++) {
ret.push(it->toSBasis(), i);
}
return ret;
We have argued endlessly about the semantics of closed and open paths.
Paths have a flag to say whether they are open or closed, whereas d2<pw>
does not have that notion. This is because the correct behaviour when
transforming a d2<pw> is not always clear wrt the closing segment. For
example, the closing segment is always a line, but if we have a transform
which does not preserve lines then should we transform that last line? I
would argue yes in many cases. Thus, we should include the last line
segment as a linear() in the d2.
Looking at the code, I would say that
- for(const_iterator it = begin(); it != end_default(); ++it, i++) {
is correct. I don't know why you made the change - there might be a bug
elsewhere that this obscured (*gasp*).
njh
|
|
From: Marco <mrc...@gm...> - 2008-04-16 13:46:01
|
On Wed, 16 Apr 2008 12:05:38 +0200, Maximilian Albert <Anh...@gm...> wrote: > J.B...@ew... schrieb: > >>> However, I have noticed that drawing operations are >>> considerably slower when 2geom is used. The ellipse tool with >>> the new code always lags a bit behind the mouse pointer. >> > > Which ellipse tool do you mean? Inkscape does not use 2geom's ellipse > > calculations, except for LPEs in rare cases. > > Oh, I thought that Marco's new code was now used for drawing ellipses in > Inkscape (after you merged it into trunk). Sorry if I got it wrong. But > if it's not 2geom what else could slow it down? Hmm, I just tried some > other tools and they all seem to respond more slowly. So it's probably > something else indeed. I sincerely apologize for unjustifiably blaming > 2geom. :) > > Max > I noticed that issue in 0.46, too, and I'm wondering what's the reason. About my elliptical arc class, sometime I see a cpu peak when I utilize the related toy but I have never suffered of responsive issues. The computational expensive part happens when you create a new elliptical arc object because the angle params related to arc extremes and the center coordinates of the supporting ellipse are evaluated. The other native routines are really simple. Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Maximilian A. <Anh...@gm...> - 2008-04-16 10:05:55
|
J.B...@ew... schrieb: >> However, I have noticed that drawing operations are >> considerably slower when 2geom is used. The ellipse tool with >> the new code always lags a bit behind the mouse pointer. > > Which ellipse tool do you mean? Inkscape does not use 2geom's ellipse > calculations, except for LPEs in rare cases. Oh, I thought that Marco's new code was now used for drawing ellipses in Inkscape (after you merged it into trunk). Sorry if I got it wrong. But if it's not 2geom what else could slow it down? Hmm, I just tried some other tools and they all seem to respond more slowly. So it's probably something else indeed. I sincerely apologize for unjustifiably blaming 2geom. :) Max |
1 message has been excluded from this view by a project administrator.
