Re: [Inkscape-devel] Snapping should only occur at the end of a movement
On 10/25/2008 05:22 PM, Vladimir Savic wrote:
- If "Always snap" is on, turn off detection of motion speed.
For grids, "always snap" is on by default. I'd prefer to have a gain in responsiveness also when using grids.
- Wait a few milliseconds when snapping occurs to avoid re-snapping
glitches
That would just act as a low-pass filter, wouldn't it? It would just reduce the jumpiness but not eliminate it completely.
- Works fine with wacom graphire3 tablet :)
Glad to hear! Thanks,
Diederik
Diederik en Rezi wrote:
On 10/25/2008 05:22 PM, Vladimir Savic wrote:
- If "Always snap" is on, turn off detection of motion speed.
For grids, "always snap" is on by default. I'd prefer to have a gain in responsiveness also when using grids.
Do you think we are getting insignificantly better performance by determining motion speed even in "always snap" mode? I don't know, honestly. Haven't tried it at complex drawing, but I think I like 0.46 version behavior better. Only in this situation, though.
To see some side-effects of recent changes in snapping code, try this situation: pick pencil tool and draw with snapping to grid on. Observe how many nodes are being added to resulting path without reason.
- Wait a few milliseconds when snapping occurs to avoid re-snapping
glitches
That would just act as a low-pass filter, wouldn't it? It would just reduce the jumpiness but not eliminate it completely.
I think this will have much more psychological effect then anything. User know that snapping will occur. He/she picks a tool for work and draws/moves/whatever. If distance is more then, let's say, 50px first move(s) will probably be the longest one(s). Snapping happened somewhere. Now, the interesting part. Pointer moves really near. Not more then 10-15 pixels. Snapping again. At this stage user either quickly releases click as he/she already saw everything is in place _or_ wants to make sure everything is in place by making small movements around target (almost like tablet input device jitter). If jerking of redraws doesn't happen now user will be convinced that the job is done.
Careful choice of snapping time delay will _probably_ make jitter much less present. Maybe the same approach would help in previously described situation. I'm not really sure...
Slightly off-thread but on-topic: 1) Who reincarnated radio buttons in Snap to grids and Snap to guides? 2) Maybe snap dialog could be cleaned out a bit.
Thank you Diederik, Vlada
Diederik
On 10/26/2008 07:47 PM, Vladimir Savic wrote:
To see some side-effects of recent changes in snapping code, try this situation: pick pencil tool and draw with snapping to grid on. Observe how many nodes are being added to resulting path without reason.
This has been fixed. Please test :-)
On 10/26/2008 07:47 PM, Vladimir Savic wrote:
Careful choice of snapping time delay will _probably_ make jitter much less present.
I've changed the snapping behavior in my latest commit, once again. Inkscape now always postpones snapping until the mouse movement has settled, and after that waits for and additional 400 msec. It will now snap only once, at the end of the movement. We still have the speed threshold to eliminate any tablet jitter, but it's at 0.02 px/msec. And if we happen to have any jitter then Inkscape will snap never more than 2.5 times per second. I really like this already, because now the snapping is very predictable and no processing power is wasted at all. Please test this and tell me if you like it too!
Another thing that I've added is that when finding the node with the best snap, we now also consider the initial distance to the mouse pointer, not just the distance to the snapped point. This way you can indicate which node you would like to snap by grabbing the selected item at that specific node. I've used a weight factor for this, which you can adjust on line 80 of snapped-point.cpp (for those who want to play with this):
double const w = 0.25; // weigth factor: controls which node should be preferrerd for snapping, which is either // the node with the closest snap (w = 0), or the node closest to the mousepointer (w = 1)
When set to 0, it won't always work as expected. I still have to look into this. Maybe we can provide a slider in the UI one day to adjust this weight factor dynamically, if we're going this route.
Regards,
Diederik
Diederik van Lierop wrote:
On 10/26/2008 07:47 PM, Vladimir Savic wrote:
Careful choice of snapping time delay will _probably_ make jitter much less present.
I've changed the snapping behavior in my latest commit, once again. Inkscape now always postpones snapping until the mouse movement has settled, and after that waits for and additional 400 msec. It will now snap only once, at the end of the movement. We still have the speed threshold to eliminate any tablet jitter, but it's at 0.02 px/msec. And if we happen to have any jitter then Inkscape will snap never more than 2.5 times per second. I really like this already, because now the snapping is very predictable and no processing power is wasted at all. Please test this and tell me if you like it too!
I've started experimenting yesterday. And what I must say is congratulation! :)
Snapping works now better then ever. There are only few things I've noticed so far. First, snapping occurs at end of movement, but what happens with starting point. The most obvious case is when creating objects. Take drawing rectangle with grid lines turned on, as example. Starting point (upper left) will always "hang" between grids. Of course, if you're not lucky enough to hit left mouse button at right place. :)
Second problem. This has nothing to do with grids. Draw rectangle and vertical line beside it. Drag middle side arrow to expand rectangle and you'll see that it simply wont snap to line. Dragging rectangle's corner arrow will. Although I can think of many use cases where it would be appropriate to keep object's height or width, it's not possible at the moment.
And the last thing... Think of better snap indicator. I can cover present one too easily with mouse pointer. Especially if using a bit "bigger" mouse pointer theme. KDE4 has oxygen which quite problematic for snapping.
Finally, I am confident in snapper doing right thing. You really deserve all the glory. Great work!
BTW, what's your IRC nick? Can't seem to find you there.
Vlada
Another thing that I've added is that when finding the node with the best snap, we now also consider the initial distance to the mouse pointer, not just the distance to the snapped point. This way you can indicate which node you would like to snap by grabbing the selected item at that specific node. I've used a weight factor for this, which you can adjust on line 80 of snapped-point.cpp (for those who want to play with this):
double const w = 0.25; // weigth factor: controls which node should be preferrerd for snapping, which is either // the node with the closest snap (w = 0), or the node closest to the mousepointer (w = 1)
When set to 0, it won't always work as expected. I still have to look into this. Maybe we can provide a slider in the UI one day to adjust this weight factor dynamically, if we're going this route.
Regards,
Diederik
On 10/29/2008 02:29 PM, Vladimir Savic wrote:
I've started experimenting yesterday. And what I must say is congratulation! :) Snapping works now better then ever.
Thanks! That's of course always nice to hear :-)
There are only few things I've noticed so far. First, snapping occurs at end of movement, but what happens with starting point.
This I should have noticed myself. Nevertheless, I think I just fixed this.
Second problem. This has nothing to do with grids. Draw rectangle and vertical line beside it. Drag middle side arrow to expand rectangle and you'll see that it simply wont snap to line. Dragging rectangle's corner arrow will. Although I can think of many use cases where it would be appropriate to keep object's height or width, it's not possible at the moment.
Are you sure? At first I thought that I could reproduce this, but that was only because I had the snapping parameters set-up wrong. A few things should be checked to avoid any confusion: make sure to select "snap to paths", set the snapping distance to max. for the object snapper, and wait at least for 400 msec for the snapping to kick in. Can you still reproduce it? If so, please send me your svg file.
And the last thing... Think of better snap indicator. I can cover present one too easily with mouse pointer. Especially if using a bit "bigger" mouse pointer theme. KDE4 has oxygen which quite problematic for snapping.
That's a stock GTK indicator I believe, it's the best we have at the moment. But it indeed is small and also too thin to notice, you're right about that. It's on my wish list to have it replaced, but I'm not sure what this would take...
BTW, what's your IRC nick? Can't seem to find you there.
I'm not on IRC, sorry. Just drop me a mail directly....
Bye,
Diederik
Diederik van Lierop wrote:
On 10/29/2008 02:29 PM, Vladimir Savic wrote:
I've started experimenting yesterday. And what I must say is congratulation! :) Snapping works now better then ever.
Thanks! That's of course always nice to hear :-)
You're welcome. ;)
Second problem...
Can you still reproduce it?
No. You were right. It was all about our obscure snapping configuration problem. Something really needs to be done here. I can't imaging all our user to be rocket scientist (in inkscape configuration area), especially the first time they are introduced to application.
And the last thing... Think of better snap indicator. I can cover present one too easily with mouse pointer. Especially if using a bit "bigger" mouse pointer theme. KDE4 has oxygen which quite problematic for snapping.
That's a stock GTK indicator I believe, it's the best we have at the moment. But it indeed is small and also too thin to notice, you're right about that. It's on my wish list to have it replaced, but I'm not sure what this would take...
It's just temporary path. Isn't it? I'm pretty sure it has nothing to do with GTK+ alone.
More observations:
When freehand path drawing (pencil tool) gets intercepted by snapping, it became almost useless. Try this, the simplest case: In new document turn on "Snap to page border" only and switch to pencil tool. Start drawing outside page and then head toward the border itself. Wait until first snapping starts and continue drawing inside page area.
Next one. Try attached .svg file. Grab lower object by placing pointer at X-like drawn hole, click and gently move up to touch upper object. I get no snapping. It might be something with tweaking existing "weight" variable, although I'll try not compiling manually changed source. Unless you specifically say so. :)
Rgds, Vlada
Bye,
Diederik
participants (3)
-
Diederik en Rezi -
Diederik van Lierop -
Vladimir Savic