Hi all,
When I have opportunities, I like to try out Inkscape for some of my freelance work and take notes. My freelance work is mostly doing artwork for those t-shirts you see in kiosks at the mall. Think "Coolest Grandpa in the World". A lot of tracing and finishing of scanned drawings. Anyway, I realized that I had a lot of notes from over several months and I thought I'd finally gather them together and send them to the list.
I love the MMB panning and zooming, especially now that I can MMB pan even while I am in the middle of drawing a path with the pen tool. Is there any reason that Shift+MMB+drag couldn't serve the same function as LMB+drag with the zoom tool (zooming in on the area you've just dragged a box around)? I think it would really complete the middle mouse button as a document navigation tool. Shift+MMB+drag currently just pans the document, the same as regular MMB dragging.
Dialogs pop-up to the front whenever I hover for more than a second over a toolbar button or menu. They appear to pop up simultaneously with the tooltips. This is under Win2k, It works correctly in Ubuntu.
Is there any way that the HSL color picker could be fixed so that changing the value of one component would not affect the values of the other components? For instance, setting S to 0 often snaps H to 0 also. Other, less drastic value changes occasionally occur too. It is frustrating to pick out the exact hue I want, only to have it change when I start tinkering with the saturation or lightness.
Align nodes is nice, but it would be more useful if there was an option to align to the center or average of the selected nodes.
I love the node editing tool, especially now that i can drag curve segments and double click to add nodes! I use Illustrator at work and at home for freelance jobs and I must say that the path editing UI is one area where I find Inkscape to be head and shoulders above AI. The only problem is the speed. Forgive me for mentioning it (since I know everyone is aware of the slow rendering), but more than any other drawback this is the one that can turn using Inkscape from a pleasure into a headache. I've brought this up before, and people mentioned profiling, but it is a little bit over my head. I don't know if it is still worth doing, but some instructions are available at http://wiki.inkscape.org/cgi-bin/wiki.pl?Profiling for those who would like to try (maybe this page should be linked to the TestingInkscape page?).
Anyway, I hope these notes are helpful. -Mike
On 9/17/05, Michael Wheeler <mpwheeler@...400...> wrote:
I love the MMB panning and zooming, especially now that I can MMB pan even while I am in the middle of drawing a path with the pen tool. Is there any reason that Shift+MMB+drag couldn't serve the same function as LMB+drag with the zoom tool (zooming in on the area you've just dragged a box around)? I think it would really complete the middle mouse button as a document navigation tool. Shift+MMB+drag currently just pans the document, the same as regular MMB dragging.
That's a very interesting idea. I like it. Though it's not a one-liner to implement, since it will require moving most of the functionality of the zoom tool into the root event context so it's available to all tools. But it's doable. Will you please file a RFE?
Dialogs pop-up to the front whenever I hover for more than a second over a toolbar button or menu. They appear to pop up simultaneously with the tooltips. This is under Win2k, It works correctly in Ubuntu.
Actually dialogs are supposed to be always on top, the fact that they sink on windows is a well known bug.
Is there any way that the HSL color picker could be fixed so that changing the value of one component would not affect the values of the other components? For instance, setting S to 0 often snaps H to 0 also. Other, less drastic value changes occasionally occur too. It is frustrating to pick out the exact hue I want, only to have it change when I start tinkering with the saturation or lightness.
I'm afraid not, because there's not a 1:1 correspondence between RGB and HSL, and since the colors are stored in RGB (in SVG 1.1 at least), each change of a channel causes a complete HSL->RGB->HSL roundtrip which may affect more than the single channel you changed.
Align nodes is nice, but it would be more useful if there was an option to align to the center or average of the selected nodes.
Doable, please file a RFE too.
I love the node editing tool, especially now that i can drag curve segments and double click to add nodes! I use Illustrator at work and at home for freelance jobs and I must say that the path editing UI is one area where I find Inkscape to be head and shoulders above AI. The only problem is the speed. Forgive me for mentioning it (since I know everyone is aware of the slow rendering), but more than any other drawback this is the one that can turn using Inkscape from a pleasure into a headache. I've brought this up before, and people mentioned profiling, but it is a little bit over my head. I don't know if it is still worth doing, but some instructions are available at http://wiki.inkscape.org/cgi-bin/wiki.pl?Profiling for those who would like to try (maybe this page should be linked to the TestingInkscape page?).
I did some experiments long ago and found that most of the slowness is caused by the renderer, not by the node tool itself. So I think our only hope is Cairo becoming drastically faster than it is and than our current renderer, and then switching to it.
On 9/17/05, bulia byak <buliabyak@...400...> wrote:
I'm afraid not, because there's not a 1:1 correspondence between RGB and HSL, and since the colors are stored in RGB (in SVG 1.1 at least), each change of a channel causes a complete HSL->RGB->HSL roundtrip which may affect more than the single channel you changed.
More info in this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1221603&gro...
On Sat, 2005-09-17 at 20:15 -0300, bulia byak wrote:
I did some experiments long ago and found that most of the slowness is caused by the renderer, not by the node tool itself. So I think our only hope is Cairo becoming drastically faster than it is and than our current renderer, and then switching to it.
Before someone requests a switch to turn off antialiasing again, thinking it would make things much faster...
The last time I checked, when we get bogged down on complex paths, the majority of time in our current renderer is spent subdividing and eliminating self-intersections, rather than in rasterizing (which is where antialiasing is involved).
-mental
I've submitted the RFEs.
I kind of figured that the HSL thing had something to do with the RGB -> HSL conversion, but I figured I'd mention it just in case there was something that could be done.
I did some experiments long ago and found that most of the slowness is caused by the renderer, not by the node tool itself. So I think our only hope is Cairo becoming drastically faster than it is and than our current renderer, and then switching to it.
I can't wait for Cairo to get fast, but I get the impression from reading the list that I may be waiting a while. Would it help things out at all if IS just drew a preview of the affected bezier segments as points were being dragged and waited to redraw the actual shape until after the mouse button was released (similar to what Illustrator does)? I've done some simple experiments and it seems that if I snip and break apart a small segment from a complex, choppily-updating path the small segments would update fairly smoothly as I tweaked them with the node tool. If that sounds promising (or if you don't quite understand what I am getting at) I could make some mock-ups of how I imagine it might look.
-Mike
Quoting Michael Wheeler <mpwheeler@...400...>:
I can't wait for Cairo to get fast, but I get the impression from reading the list that I may be waiting a while. Would it help things out at all if IS just drew a preview of the affected bezier segments as points were being dragged and waited to redraw the actual shape until after the mouse button was released (similar to what Illustrator does)?
Alternately, you could modify the canvas and SPShape code so that:
1. NRArenaShape only feeds the section of the path that lies within the update region to the renderer
2. SPShape only requests an update for the bbox of the _changed portion_ of the path in the first place (rather than the whole thing)
I can elaborate on the algorithms necessary to do this if you would like -- there are some finer points WRT including enough extra path context to get a correct rendering, and maintaining correct dash offsets.
This is something I've been meaning to do for a while myself, but I simply haven't had time to do much coding these days.
-mental
participants (4)
-
unknown＠example.com -
bulia byak -
MenTaLguY -
Michael Wheeler