Menu
▾
▴
lib2geom-devel
|
From: Maximilian A. <Anh...@gm...> - 2008-04-16 09:39:58
|
J.B...@ew... schrieb: > Hi Marco, > > I just committed it to Inkscape trunk (did a 2geom re-sync). I believe that every enhancement of 2geom and further integration into Inkscape is a great improvement. Thanks to everyone for your work on this! And just in case I haven't mentioned it recently -- 2geom is simply awesome to work with. :) 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? Max |
|
From: <J.B...@ew...> - 2008-04-16 09:52:57
|
> -----Original Message----- > From: lib...@li... > [mailto:lib...@li...] On > Behalf Of Maximilian Albert > Sent: woensdag 16 april 2008 11:40 > To: lib...@li... > Subject: Re: [Lib2geom-devel] [Inkscape-devel] > newSVGEllipticalArcimplementation merged intopath.h > > J.B...@ew... schrieb: > > Hi Marco, > > > > I just committed it to Inkscape trunk (did a 2geom re-sync). > > I believe that every enhancement of 2geom and further > integration into Inkscape is a great improvement. Thanks to > everyone for your work on this! And just in case I haven't > mentioned it recently -- 2geom is simply awesome to work with. :) > > 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. > 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? LPE is a bit slow because of all the type conversions involved. Switching Inkscape to use 2geom types will solve this. The conversion from Inkscape to 2geom is done through an SVGD string... Regards, Johan |
|
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 |
|
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: 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: <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-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-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 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 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: 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: <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 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: 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X