Careful, you never know what other lists the Inkscape developers are subscribed to. :)
Quoting Vladimir Savic <vladimir@...958...>:
You cann't imagine the amount... One of most obvious is strange development course. We say "as with left leg writen" code. Optimisation is ...awesome... more then 1000 nodes and my box is literally dieing.
This is largely attributable to the current renderer. Parts of it have something like O(n^2) performance with the number of segments.
Unfortunately none of the current developers have simultaneously the time and the expertise to replace it (numerical stability, the really hard part, is as critical as speed).
We do plan to replace it with Cairo when that's ready, but realistically that probably can't happen at least until Cairo's 1.0 release.
In the meantime, any volunteers to help with cleaning up the rendering code would be very, very welcome.
And here we are -- for comfortable using of fonts -- YOU NEED A WORKING TOOL!!!! Font dialog is broken since 1950 - and chrushes the inkscape every single time.
This bug is new bug to us. The font dialog is crappy, but it doesn't crash for most users. Could you please report it in the bug tracker?
My guess is it's a bug exposed by the particular combination of fonts, languages, and libraries on your system -- so all the information you can give us would be helpful.
-mental
On Fri, 2005-08-12 at 14:06 -0400, mental@...3... wrote:
Careful, you never know what other lists the Inkscape developers are subscribed to. :)
Quoting Vladimir Savic <vladimir@...958...>:
You cann't imagine the amount... One of most obvious is strange development course. We say "as with left leg writen" code. Optimisation is ...awesome... more then 1000 nodes and my box is literally dieing.
This is largely attributable to the current renderer. Parts of it have something like O(n^2) performance with the number of segments.
Unfortunately none of the current developers have simultaneously the time and the expertise to replace it (numerical stability, the really hard part, is as critical as speed).
We do plan to replace it with Cairo when that's ready, but realistically that probably can't happen at least until Cairo's 1.0 release.
In the meantime, any volunteers to help with cleaning up the rendering code would be very, very welcome.
And here we are -- for comfortable using of fonts -- YOU NEED A WORKING TOOL!!!! Font dialog is broken since 1950 - and chrushes the inkscape every single time.
This bug is new bug to us. The font dialog is crappy, but it doesn't crash for most users. Could you please report it in the bug tracker?
My guess is it's a bug exposed by the particular combination of fonts, languages, and libraries on your system -- so all the information you can give us would be helpful.
I had a crash problem with the font dialog and did a backtrace and found it happened to be an out of date aspell library.
Maybe you all could provide a backtrace of the font dialog crash. Here are my versions:
app-text/aspell-0.50.5-r4 app-dicts/aspell-en-0.51.1
Jon
On 8/12/05, Jon Phillips <jon@...235...> wrote:
Ahem, these faces look familiar to me :))))
My guess is it's a bug exposed by the particular combination of fonts, languages, and libraries on your system -- so all the information you can give us would be helpful.
I had a crash problem with the font dialog and did a backtrace and found it happened to be an out of date aspell library.
Maybe you all could provide a backtrace of the font dialog crash. Here are my versions:
app-text/aspell-0.50.5-r4 app-dicts/aspell-en-0.51.1
I'm curious why there is no enchant related switch in Inkscape's ./configure and why spellchecking doesn't work if it tries to use enchant anyway :)
P.S. Aren't we going offtopic in rosegarden-devel? :)
Alexandre
On Fri, 12 Aug 2005 18:19:44 -0000, Jon Phillips <jon@...235...> wrote:
On Fri, 2005-08-12 at 14:06 -0400, mental@...3... wrote:
I had a crash problem with the font dialog and did a backtrace and found it happened to be an out of date aspell library.
Maybe you all could provide a backtrace of the font dialog crash. Here are my versions:
app-text/aspell-0.50.5-r4 app-dicts/aspell-en-0.51.1
emerge says:
app-text/aspell-0.50.3 app-dicts/aspell-en-0.51.0
Should I upgrade?
Vlada
Jon
On Fri, 2005-08-12 at 21:36 +0000, Vladimir Savic wrote:
On Fri, 12 Aug 2005 18:19:44 -0000, Jon Phillips <jon@...235...> wrote:
On Fri, 2005-08-12 at 14:06 -0400, mental@...3... wrote:
I had a crash problem with the font dialog and did a backtrace and found it happened to be an out of date aspell library.
Maybe you all could provide a backtrace of the font dialog crash. Here are my versions:
app-text/aspell-0.50.5-r4 app-dicts/aspell-en-0.51.1
emerge says:
app-text/aspell-0.50.3 app-dicts/aspell-en-0.51.0
Should I upgrade?
Yeah, that is what I did for it to work.
Jon
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 12 Aug 2005 19:48:58 -0000, Jon Phillips <jon@...235...> wrote:
On Fri, 2005-08-12 at 21:36 +0000, Vladimir Savic wrote:
On Fri, 12 Aug 2005 18:19:44 -0000, Jon Phillips <jon@...235...> wrote:
On Fri, 2005-08-12 at 14:06 -0400, mental@...3... wrote:
I had a crash problem with the font dialog and did a backtrace and
found
it happened to be an out of date aspell library.
Maybe you all could provide a backtrace of the font dialog crash. Here are my versions:
app-text/aspell-0.50.5-r4 app-dicts/aspell-en-0.51.1
emerge says:
app-text/aspell-0.50.3 app-dicts/aspell-en-0.51.0
Should I upgrade?
Yeah, that is what I did for it to work.
Works for me now. Great! BTW, Autotools should remind me to upgrade obsolete software, not to overlook possible problems!
Vlada
Jon
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 12 Aug 2005 18:06:53 -0000, <mental@...3...> wrote:
Careful, you never know what other lists the Inkscape developers are subscribed to. :)
I simply can not live without you inkscapers! :) You're guitar player, aren't you? :)
Quoting Vladimir Savic <vladimir@...958...>:
You cann't imagine the amount... One of most obvious is strange development course. We say "as with left leg writen" code. Optimisation is ...awesome... more then 1000 nodes and my box is literally dieing.
This is largely attributable to the current renderer. Parts of it have something like O(n^2) performance with the number of segments.
More serious problem is handling of "zoom factor". The more you zoom in the more time it eats to calculate something outside visible canvas area!? At least it looks like inkscape does that.
Vlada
Quoting Vladimir Savic <vladimir@...958...>:
I simply can not live without you inkscapers! :) You're guitar player, aren't you? :)
Keyboardist, actually. More of a composer than a performer though.
I have some (very old) work up online at http://moonbase.rydia.net/mental/music ... Pop and Video Game stuff mostly ... someday soon I intend to put up some more recent work which was done with Rosegarden.
More serious problem is handling of "zoom factor". The more you zoom in the more time it eats to calculate something outside visible canvas area!?
Sort of, yeah. I'm not sure whether to blame our renderer or our canvas widget (a heavily bastardized GnomeCanvas), though.
Every time you move the mouse, it checks which shape the mouse pointer is inside. To perform the actual shape intersection check, it asks the renderer, using the computed shape cached during drawing.
To do this, the renderer just iterates through the shape and counts edges. Unfortunately, if the shape had curves in it, there will be a lot of edges -- beziers are internally divided into tiny straight line segments. The higher the zoom, the more finely divided, the more edges, the longer it takes.
There are really two problems:
1. edge lists are the wrong data structure for this operation: we should be keeping a BSP tree or something which is more efficient for these purposes
2. the current renderer has horrible performance characteristics: our previous renderer was used the same way, but performance was at least tolerable
The reason we abandoned the renderer we inherited from Sodipodi, despite it being tolerably fast, was that it had severe rendering bugs and crashes in corner cases, and was unmaintainable.
The new renderer, which we got as an emergency replacement, renders things properly, but is dog slow and has also proven unmaintainable (simply replacing the guy's open-coded realloc()s with std::vector proved to be a multi-month project).
Really, we need a renderer that is all three of:
1. Fast 2. Correct 3. Maintainable
No "pick any two" comments, please. :) But really I'd settle for just #3, since that means it is still possible to fix the other two.
(Of course that is precisely the approach Cairo is taking -- they got #3, then attacked #2, and are now mainly working on #1.)
-mental
participants (4)
-
unknown＠example.com -
Alexandre Prokoudine -
Jon Phillips -
Vladimir Savic