Fill and Stroke Dialog
Hi Everyone,
I was playing around with the June 4th Win32 build and I noticed that the Fill and Stroke dialog is slow to come up. I haven't been using all of the daily builds, so I don't know where the problem started, but the dialog is snappy for me in 0.38. Also, changing the colors in the dialog is less smooth. The other dialogs seem just fine.
By the way, the working eyedropper is great. I like that it keeps things real simple. How would people feel if it used a crosshair rather than the white arrow. Maybe this is silly, but I am always feel a little unsure what specific point I am aiming at with the arrow.
Thanks, Michael Wheeler http://www.planet-zero.net
On Sat, 5 Jun 2004, Michael Wheeler wrote:
Hi Everyone,
I was playing around with the June 4th Win32 build and I noticed that the Fill and Stroke dialog is slow to come up. I haven't been using all of the daily builds, so I don't know where the problem started, but the dialog is snappy for me in 0.38. Also, changing the colors in the dialog is less smooth. The other dialogs seem just fine.
Hmm... There have been only a few changes to that dialog; the only significant one I know about is the addition of the marker previews. Can you look on the Stroke Style page and see if your marker dropdowns have the previews they should? I'm wondering if perhaps it's getting stuck loading those up. Otherwise, the dialog is pretty straightforward and concise Gtk code so it shouldn't be taking much time to load.
Have you had any other problems with loading times? There are reports that the Windows Gtk port is sluggish, so I'm wondering if this might simply be a symptom of that larger issue.
Can you give us some additional details about your system hardware, OS and versions of Inkscape dependencies, etc.? There have been several reported performance issues with Inkscape on Windows, and perhaps there is a commonality we could identify to help isolate the issue.
By the way, the working eyedropper is great. I like that it keeps things real simple. How would people feel if it used a crosshair rather than the white arrow. Maybe this is silly, but I am always feel a little unsure what specific point I am aiming at with the arrow.
Not a bad idea -- can you submit this as a Feature Request?
Thanks, Bryce
I must conform that compared to 0.38, and a 20-days-old snapshot, the yesterday's snapshot has a very slowly-appearing (heavy) fill/stroke dialogue. 15-20 days ago, even when the marker previews were there, it was as fast as in 0.38 (or at least closer). But now it takes around 1.5-2 seconds to show up which is really slow - inkscape itself fires up in 5-6 seconds.
Artemio.
On Sat, 2004-06-05 at 15:15, Artemio wrote:
I must conform that compared to 0.38, and a 20-days-old snapshot, the yesterday's snapshot has a very slowly-appearing (heavy) fill/stroke dialogue. 15-20 days ago, even when the marker previews were there, it was as fast as in 0.38 (or at least closer). But now it takes around 1.5-2 seconds to show up which is really slow - inkscape itself fires up in 5-6 seconds.
Hmm, sounds like it's time to do a profiling build and figure out where it's spending all its time.
My guess is it's either an arena or a livarot thing, but we'll see. For my part I have been reworking the style stuff in NRArenaShape, but I'd be a little surprised if were this much slower...
-mental
Bryce Harrington wrote:
On Sat, 5 Jun 2004, Michael Wheeler wrote:
Hi Everyone,
I was playing around with the June 4th Win32 build and I noticed that the Fill and Stroke dialog is slow to come up. I haven't been using all of the daily builds, so I don't know where the problem started, but the dialog is snappy for me in 0.38. Also, changing the colors in the dialog is less smooth. The other dialogs seem just fine.
Hmm... There have been only a few changes to that dialog; the only significant one I know about is the addition of the marker previews. Can you look on the Stroke Style page and see if your marker dropdowns have the previews they should? I'm wondering if perhaps it's getting stuck loading those up. Otherwise, the dialog is pretty straightforward and concise Gtk code so it shouldn't be taking much time to load.
The marker previews are there and working, although the scroll thing that they pop up in is a little goofy. However it seems like it may be the marker previews that are causing the delays. I renamed the markers.svg file and the F&S dialog came up quick as a whip. Of course, there are no longer any markers to pick from.
Have you had any other problems with loading times? There are reports that the Windows Gtk port is sluggish, so I'm wondering if this might simply be a symptom of that larger issue.
Can you give us some additional details about your system hardware, OS and versions of Inkscape dependencies, etc.? There have been several reported performance issues with Inkscape on Windows, and perhaps there is a commonality we could identify to help isolate the issue.
Other than this one problem Inkscape has been pretty speedy on my computer. Panning the drawing with the middle mouse button is not quite as smooth as on Linux, but is still very usable. It is a Pentium 3 - 733mhz - 384 MB memory running win2000. I'm not sure what to check concerning dependencies...
Thanks, Michael Wheeler http://www.planet-zero.net
On Sat, 5 Jun 2004, Michael Wheeler wrote:
Bryce Harrington wrote:
Hmm... There have been only a few changes to that dialog; the only significant one I know about is the addition of the marker previews. Can you look on the Stroke Style page and see if your marker dropdowns have the previews they should? I'm wondering if perhaps it's getting stuck loading those up. Otherwise, the dialog is pretty straightforward and concise Gtk code so it shouldn't be taking much time to load.
The marker previews are there and working, although the scroll thing that they pop up in is a little goofy. However it seems like it may be the marker previews that are causing the delays. I renamed the markers.svg file and the F&S dialog came up quick as a whip. Of course, there are no longer any markers to pick from.
Okay, sounds like that's our culprit. Next thing - can you experiment and see if it happens to be a particular marker that's causing the trouble? Try removing them one by one from markers.svg, especially look for ones that require excessive amounts of SVG to describe or that have complex features in them that might be causing extra rendering time. My bet is that there's just one or two markers that are getting the renderer into a loop, and if they can be redrawn more carefully, it will resolve the issue.
Bryce
Bryce Harrington wrote:
The marker previews are there and working, although the scroll thing that they pop up in is a little goofy. However it seems like it may be the marker previews that are causing the delays. I renamed the markers.svg file and the F&S dialog came up quick as a whip. Of course, there are no longer any markers to pick from.
Okay, sounds like that's our culprit. Next thing - can you experiment and see if it happens to be a particular marker that's causing the trouble? Try removing them one by one from markers.svg, especially look for ones that require excessive amounts of SVG to describe or that have complex features in them that might be causing extra rendering time. My bet is that there's just one or two markers that are getting the renderer into a loop, and if they can be redrawn more carefully, it will resolve the issue.
Bryce
I just gave this a try and I couldn't identify any one marker that was causing the problem. The delay just gradually got longer as I went from zero to all markers. I did notice that if I hid the dialog using F12 it would pop back up quickly on the next F12 or Ctrl+Shift+F. Maybe that helps...
Thanks, Michael Wheeler http://www.planet-zero.net
On Sun, 6 Jun 2004, Michael Wheeler wrote:
Bryce Harrington wrote:
The marker previews are there and working, although the scroll thing that they pop up in is a little goofy. However it seems like it may be the marker previews that are causing the delays. I renamed the markers.svg file and the F&S dialog came up quick as a whip. Of course, there are no longer any markers to pick from.
Okay, sounds like that's our culprit. Next thing - can you experiment and see if it happens to be a particular marker that's causing the trouble? Try removing them one by one from markers.svg, especially look for ones that require excessive amounts of SVG to describe or that have complex features in them that might be causing extra rendering time. My bet is that there's just one or two markers that are getting the renderer into a loop, and if they can be redrawn more carefully, it will resolve the issue.
Bryce
I just gave this a try and I couldn't identify any one marker that was causing the problem. The delay just gradually got longer as I went from zero to all markers. I did notice that if I hid the dialog using F12 it would pop back up quickly on the next F12 or Ctrl+Shift+F. Maybe that helps...
Okay, cool, thanks. That rules out that it's a bad marker. Simarilius has an idea that it might be due to some changes in the fill/stroke dialog in the get_stock stuff. Mental suggests we do some profiling to narrow it down more precisely, and he's probably right. ;-)
Bryce
On Sat, 2004-06-05 at 13:55, Michael Wheeler wrote:
I was playing around with the June 4th Win32 build and I noticed that the Fill and Stroke dialog is slow to come up. I haven't been using all of the daily builds, so I don't know where the problem started, but the dialog is snappy for me in 0.38.
I noticed that too a while back, but hadn't had a chance to look into it before. I just ran it through gdb and verified that it is spending most of its time rendering the marker previews (not hanging on anything, it's just CPU-bound).
Also, changing the colors in the dialog is less smooth. The other dialogs seem just fine.
I haven't noticed that myself, though some other updates seem slower lately (e.g. movement of selection hints with object transformations).
By the way, the working eyedropper is great. I like that it keeps things real simple. How would people feel if it used a crosshair rather than the white arrow. Maybe this is silly, but I am always feel a little unsure what specific point I am aiming at with the arrow.
Yeah, that's probably a good idea. Let me dust off my pixel art skills and see what I can do ^^;
-mental
On Sat, 2004-06-05 at 13:55, Michael Wheeler wrote:
By the way, the working eyedropper is great. I like that it keeps things real simple. How would people feel if it used a crosshair rather than the white arrow. Maybe this is silly, but I am always feel a little unsure what specific point I am aiming at with the arrow.
How does this look? (attached)
-mental
MenTaLguY wrote:
How does this look? (attached)
-mental
That looks pretty sharp to me. I took a shot at making the crosshair a bit bigger, but I'm not sure if it is an improvement. I also tried rotating the crosshairs to the upper right corner to be more consistent with the other cursors, and because it feels a little bit more comfortable to me (maybe because that is where my index finger sits on the mouse). The upside-down eyedropper is a little strange though. I've attached all three for comparison.
Yeah, I like the dropper-cursor3.png. Seems more intuitive for the icon to be more like the pointer. People are used to the pointer mirroring the dominant right handed index finger.
Jon
On Sat, 2004-06-05 at 20:13, Michael Wheeler wrote:
MenTaLguY wrote:
How does this look? (attached)
-mental
That looks pretty sharp to me. I took a shot at making the crosshair a bit bigger, but I'm not sure if it is an improvement. I also tried rotating the crosshairs to the upper right corner to be more consistent with the other cursors, and because it feels a little bit more comfortable to me (maybe because that is where my index finger sits on the mouse). The upside-down eyedropper is a little strange though. I've attached all three for comparison.
Yeah, I like the dropper-cursor3.png. Seems more intuitive for the icon to be more like the pointer. People are used to the pointer mirroring the dominant right handed index finger.
People might be used to it in gereral, but with the eye-dropper, you're used to having the bottom left corner taking the color. I'd suggest to just go and use the system eye-dropper cursor! You know, the one you get, when you select a color for the panel, for example. This makes sense imho, cause I just got a set of new cursors, which might eventually at some point effect the eye dropper to look different.
Is there any problems with using that cursor? Why reinvent the wheel, and not maybe make the GNOME people improve theirs? What matters to me is a consistent behaviour on my desktop.
David
On Sat, 2004-06-05 at 23:13, Michael Wheeler wrote:
That looks pretty sharp to me. I took a shot at making the crosshair a bit bigger, but I'm not sure if it is an improvement. I also tried rotating the crosshairs to the upper right corner to be more consistent with the other cursors, and because it feels a little bit more comfortable to me (maybe because that is where my index finger sits on the mouse). The upside-down eyedropper is a little strange though. I've attached all three for comparison.
I like the bigger crosshairs.
Visually, I prefer the normally-oriented eyedropper (#2), but on the other hand I don't think we should sacrifice usability just for preserving a physical analogy (with a real eyedropper).
I think I'll reluctantly go with #3.
How do other folks feel about it?
-mental
We just need to be consistent. Plus, need to keep in mind that it will be nice to make little emblems on those keys eventually so that modifier keys can change functionality of tool slighty.
Jon
n Sun, 2004-06-06 at 17:10, MenTaLguY wrote:
On Sat, 2004-06-05 at 23:13, Michael Wheeler wrote:
That looks pretty sharp to me. I took a shot at making the crosshair a bit bigger, but I'm not sure if it is an improvement. I also tried rotating the crosshairs to the upper right corner to be more consistent with the other cursors, and because it feels a little bit more comfortable to me (maybe because that is where my index finger sits on the mouse). The upside-down eyedropper is a little strange though. I've attached all three for comparison.
I like the bigger crosshairs.
Visually, I prefer the normally-oriented eyedropper (#2), but on the other hand I don't think we should sacrifice usability just for preserving a physical analogy (with a real eyedropper).
I think I'll reluctantly go with #3.
How do other folks feel about it?
-mental
participants (6)
-
Artemio -
Bryce Harrington -
David Christian Berg -
Jon Phillips -
MenTaLguY -
Michael Wheeler