I recently used Inkscape for a little bit of my "real work", and I took a few notes to share. I was using the Sept 24th build on Win 2000, which I know is a bit old. I'll grab the latest build as soon as I get a chance and start taking notes with that. Anyway, take these for what they're worth...
Text on a path is very cool. It would be nice to be able to drag the starting point of the text along the curve.
Alt+Click does not seem to work to select under in the select tool.
Middle mouse pan and zoom is great and should be in every application! Maybe Shift+MM Drag could work like dragging a box with the zoom tool. It would make the middle mouse button more complete as the document navigation button. I wouldn't ever have to switch to the zoom tool. I'll make an RFE.
The open file dialog freezes for a while right after I make my first click in the file area (even if it's a directory, or other item that needs no preview)
Editing paths becomes very slow, almost to the point of becoming unusable, at high zoom levels, or with modestly complex paths.
Text Dialog takes a long time to pop up.
The font used for menus is smaller than that used by other applications.
Keep up the good work! Michael Wheeler http://www.planet-zero.net
On Mon, 2004-10-25 at 20:10, Michael Wheeler wrote:
Alt+Click does not seem to work to select under in the select tool.
This is likely to be a window manager issue; many window managers intercept alt+click/drag, unfortunately. You may or may not be able to configure yours not to steal it.
-mental
On Tue, 26 Oct 2004 00:27:10 -0400, MenTaLguY <mental@...3...> wrote:
On Mon, 2004-10-25 at 20:10, Michael Wheeler wrote:
Alt+Click does not seem to work to select under in the select tool.
This is likely to be a window manager issue; many window managers intercept alt+click/drag, unfortunately. You may or may not be able to configure yours not to steal it.
Is there a description in our Wiki how to disable it?
Alexandre
On Tue, 26 Oct 2004 13:18:41 +0400, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
This is likely to be a window manager issue; many window managers intercept alt+click/drag, unfortunately. You may or may not be able to configure yours not to steal it.
Is there a description in our Wiki how to disable it?
No but you can create a new page. Here's how I did it in KDE 3.1:
Control center -> LookNFeel -> Window Behavior -> Actions -> Inner Window, Titlebar & Frame -> Modifier key: Alt, all options below set to Nothing
Well, it wasn't a WM issue (I am using windows). I went back and took a look at it and I just didn't understand how to use it. I expected that just alt+clicking on two objects with none selected would select the bottom one. Now that I've figured out how it actually works, I realize it makes a lot more sense than how I expected it to work.
Mike
MenTaLguY wrote:
On Mon, 2004-10-25 at 20:10, Michael Wheeler wrote:
Alt+Click does not seem to work to select under in the select tool.
This is likely to be a window manager issue; many window managers intercept alt+click/drag, unfortunately. You may or may not be able to configure yours not to steal it.
-mental
Text on a path is very cool. It would be nice to be able to drag the starting point of the text along the curve.
No need to drag, you can just push the text forward by pressing space before the first character, or for finer adjustment, kern it horizontally (Alt+arrow keys).
Editing paths becomes very slow, almost to the point of becoming unusable, at high zoom levels, or with modestly complex paths.
I agree that this has become an issue. Can you please create some measurable test case (e.g. a complex path and a time measurement of some action on it) and submit it as a bug so we could track the progress in addressing this.
Text Dialog takes a long time to pop up.
That might depend on the number of fonts installed on your system.
The font used for menus is smaller than that used by other applications.
If it's on Windows then it's no fault of ours. That's what Windows GTK uses I guess.
Editing paths becomes very slow, almost to the point of becoming unusable, at high zoom levels, or with modestly complex paths.
I agree that this has become an issue. Can you please create some measurable test case (e.g. a complex path and a time measurement of some action on it) and submit it as a bug so we could track the progress in addressing this.
I'll see what I can do. Do you have any suggestions? Is there any way I should be measuring this, other than with a stopwatch? I installed 0.37 out of curiosity and it is noticeably quicker than 0.39 or the latest builds in these areas, if that helps any.
Text Dialog takes a long time to pop up.
That might depend on the number of fonts installed on your system.
I do have several fonts, but 0.39 pops up the Text Dialog in less than a second, while the Oct 22nd build takes about 14 seconds. I figured I'd break out the stopwatch for this one :)
The font used for menus is smaller than that used by other applications.
If it's on Windows then it's no fault of ours. That's what Windows GTK uses I guess.
I don't mean to be contrary, since I don't really understand the implications of using GTK, but 0.39 displays menu fonts larger than the sept 24 or Oct 22 builds on my computer. This isn't a big deal (to me), but I do think the 0.39 font size looks better.
I'll see what I can do. Do you have any suggestions? Is there any way I should be measuring this, other than with a stopwatch?
If you know how to profile, it would be nice if you could create a node-editing-specific profile (e.g. start the program with a file with a complex path, then do dragging nodes for a pretty long time so that it makes the program loading time small by comparison, and then examine the profile to see what functions take the longest time). If you don't know how to profile, ask here, it's simple (though I don't remember all details :)
I installed 0.37 out of curiosity and it is noticeably quicker than 0.39 or the latest builds in these areas, if that helps any.
Yeah. 0.37 was a very different program internally. Much simpler.
That might depend on the number of fonts installed on your system.
I do have several fonts, but 0.39 pops up the Text Dialog in less than a second, while the Oct 22nd build takes about 14 seconds. I figured I'd break out the stopwatch for this one :)
OK, please submit this as a bug too. And if you can profile this too (open it several times in a row in one session) it would be very helpful.
If it's on Windows then it's no fault of ours. That's what Windows GTK uses I guess.
I don't mean to be contrary, since I don't really understand the implications of using GTK, but 0.39 displays menu fonts larger than the sept 24 or Oct 22 builds on my computer. This isn't a big deal (to me), but I do think the 0.39 font size looks better.
Oh then it must be a consequence of the new versions of libraries. Maybe Bob Jamison will have a comment on this.
bulia byak wrote:
I'll see what I can do. Do you have any suggestions? Is there any way I should be measuring this, other than with a stopwatch?
If you know how to profile, it would be nice if you could create a node-editing-specific profile (e.g. start the program with a file with a complex path, then do dragging nodes for a pretty long time so that it makes the program loading time small by comparison, and then examine the profile to see what functions take the longest time). If you don't know how to profile, ask here, it's simple (though I don't remember all details :)
I don't know how to profile, but I'd be willing to give it a shot if someone wouldn't mind explaining it to me (and assuming it isn't over my head). I'm on Win2k.
Thanks, Michael
On Thu, 28 Oct 2004, Michael Wheeler wrote:
bulia byak wrote:
I'll see what I can do. Do you have any suggestions? Is there any way I should be measuring this, other than with a stopwatch?
If you know how to profile, it would be nice if you could create a node-editing-specific profile (e.g. start the program with a file with a complex path, then do dragging nodes for a pretty long time so that it makes the program loading time small by comparison, and then examine the profile to see what functions take the longest time). If you don't know how to profile, ask here, it's simple (though I don't remember all details :)
I don't know how to profile, but I'd be willing to give it a shot if someone wouldn't mind explaining it to me (and assuming it isn't over my head). I'm on Win2k.
Here is how I've done profiling for Inkscape in the past. I have no idea if this will work on Win32 though since profiling requires kernel calls, so you may have to do some adapting.
There are essentially three major steps:
A) Compile the application with profiling support
B) Run the application in a "certain way"
C) Run gprof to generate analysis reports
For Step A what you need to do is add the -pg option to the compiler. You can do this via the CFLAGS variable at configure time. For example in Bash:
$ CFLAGS='-pg' ./configure $ make
Step B is where some creativity is needed. You'll probably want to do several profiling runs to get the hang of it. Essentially, you want to exercise the part of the program you're most interested in measuring. For instance, if you're measuring the speed of rendering stars, you may want to create a document full of zillions of stars, and start Inkscape with that file, then immediately close when it finishes rendering.
As part of Step B, a special output file is generated (called a.out by default I think). In Step C, you run gprof on this file to generate different sorts of reports, such as the flat profile and call graph. So for example:
$ gprof --exec-counts a.out $ gprof --graph a.out
See the gprof manpage for all the analysis report options.
Bryce
Thanks for the directions. I think I could handle this under Linux, but it may be over my head with Win32. However, it seems to me that the slow rendering problems are occurring on all platforms (or is it just that my Linux box is slow?) so maybe it would still be worth it for me to give this a shot under Linux? Also, should these directions be added to the wiki?
Thanks, Mike
Bryce Harrington wrote:
Here is how I've done profiling for Inkscape in the past. I have no idea if this will work on Win32 though since profiling requires kernel calls, so you may have to do some adapting.
There are essentially three major steps:
A) Compile the application with profiling support
B) Run the application in a "certain way"
C) Run gprof to generate analysis reports
For Step A what you need to do is add the -pg option to the compiler. You can do this via the CFLAGS variable at configure time. For example in Bash:
$ CFLAGS='-pg' ./configure $ make
Step B is where some creativity is needed. You'll probably want to do several profiling runs to get the hang of it. Essentially, you want to exercise the part of the program you're most interested in measuring. For instance, if you're measuring the speed of rendering stars, you may want to create a document full of zillions of stars, and start Inkscape with that file, then immediately close when it finishes rendering.
As part of Step B, a special output file is generated (called a.out by default I think). In Step C, you run gprof on this file to generate different sorts of reports, such as the flat profile and call graph. So for example:
$ gprof --exec-counts a.out $ gprof --graph a.out
See the gprof manpage for all the analysis report options.
Bryce
On Sat, 30 Oct 2004 12:03:16 -0400, Michael Wheeler <mwheeler@...234...> wrote:
Thanks for the directions. I think I could handle this under Linux, but it may be over my head with Win32. However, it seems to me that the slow rendering problems are occurring on all platforms (or is it just that my Linux box is slow?) so maybe it would still be worth it for me to give this a shot under Linux?
I doubt our slowness has any platform-specific components, though I may be wrong.
Also, should these directions be added to the wiki?
Yes, and you can put your results there too, so that others could add to them and track the progress if any.
On Sat, 30 Oct 2004, Michael Wheeler wrote:
Thanks for the directions. I think I could handle this under Linux, but it may be over my head with Win32. However, it seems to me that the slow rendering problems are occurring on all platforms (or is it just that my Linux box is slow?) so maybe it would still be worth it for me to give this a shot under Linux?
Yeah, couldn't hurt to do it under Linux. Once you get comfortable with it there, maybe it'd not be too hard to try it under Win32.
Also, should these directions be added to the wiki?
Yes, it'd be great if you could add them. Potentially there could be a lot of profiling/optimization work to do, and a place to capture howtos and best practices would be quite valuable.
Thanks, Bryce
Bryce Harrington wrote:
Here is how I've done profiling for Inkscape in the past. I have no idea if this will work on Win32 though since profiling requires kernel calls, so you may have to do some adapting.
There are essentially three major steps:
A) Compile the application with profiling support
B) Run the application in a "certain way"
C) Run gprof to generate analysis reports
For Step A what you need to do is add the -pg option to the compiler. You can do this via the CFLAGS variable at configure time. For example in Bash:
$ CFLAGS='-pg' ./configure $ make
Step B is where some creativity is needed. You'll probably want to do several profiling runs to get the hang of it. Essentially, you want to exercise the part of the program you're most interested in measuring. For instance, if you're measuring the speed of rendering stars, you may want to create a document full of zillions of stars, and start Inkscape with that file, then immediately close when it finishes rendering.
As part of Step B, a special output file is generated (called a.out by default I think). In Step C, you run gprof on this file to generate different sorts of reports, such as the flat profile and call graph. So for example:
$ gprof --exec-counts a.out $ gprof --graph a.out
See the gprof manpage for all the analysis report options.
Bryce
participants (5)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
MenTaLguY -
Michael Wheeler