Snap.svg
Snap.svg copied to clipboard
Dragging speed scaled elements
Scaled elements move faster or slower than the mouse. Here is a simple JSFiddle showing the problem: http://jsfiddle.net/jlgrall/pjnp8zy4/
You need to incorporate the existing transform for that. I created an alternate drag plugin a while back that may be of some use to highlight it.
http://svg.dabbles.info/snaptut-dragplugin.html
I'm not quite sure if this is a bug or not, as it depends if its desired to do matrix calculations when not needed, but it feels like it trips enough people up that there should be an integral solution in there. Maybe drag calls default, drag(1) calls one that takes into account existing transformation ?
Hi, thx for your answer.
What I would do is that at the mousedown I would get the globalMatrix, see if it has scaling in it. Then during mousemove, compute either the drag with scaling or without it depending on what we detected. This way you get only more computation if needed.
Also note that the globalMatrix is always computed when you call .transform(), even if you don't use it. So it wont take more calculation compared to the current situation. And it can be cached, just as you currently cache the local transform.
Finally, I am working with Inkscape documents, and I see scalings everywhere. As soon as you start making groups and resizing them, you get scalings.
Edit: actually computation-wise I think it is far from being the bottleneck, especially when I see all the computation made in the .transform() method and whose results are not used. Also the method of the form .transform("...") is quite demanding with all its string manipulations. In our situation we already have all the data, there is only a few additional multiplications needed.
The plugin linked to does not seem to work for elements which have has scale transform applied to them. I'm trying to work out solution. To reproduce in plugin link:
var r1 = s.rect(0,0,20,20).transform('t50,50s2').attr({ fill: "red" }).altDrag();
Drag the red one and enjoy.
@cjgordon Did you ever find a solution to the problem in that plugin? I'm having the same problem and need to be able to scale the object.
Swap the transforms around, http://svg.dabbles.info/snaptut-dragplugin.php should be amended (I need to swap the php files around, but thats for another day).
What do you mean when you say "Swap the transforms around?". Can you give me an example?
The dragging transforms, in this case (and probably in general, so it would be a better solution anyway just for drags), put the dragged translation first, ie..
this.transform( "t" + [ tdx, tdy ] + this.data('ot') );
rather than
this.transform( this.data('ot') + "t" + [ tdx, tdy ] );
On Mon, Jul 6, 2015 at 8:53 AM, Ole Henrik Skogstrøm < [email protected]> wrote:
What do you mean when you say "Swap the transforms around?". Can you give me an example?
— Reply to this email directly or view it on GitHub https://github.com/adobe-webplatform/Snap.svg/issues/331#issuecomment-118762274 .
Perfect! Thank you :)
I am using the same plugin.In my app I am using jquery panzoom library where the svg is contained inside a zoomable div.The snap plugin works fine initially when zooming and panning is not applied to the parent div,but when zoomed or panned the pointer is lagging behind the image(SVG
Is this one any better ? http://svg.dabbles.info/snaptut-altdragnew
Vijaya
The problem that I ran into is that mouse clicks are based on a coordinate system that has an origin on the top left, and the transforms scale from the center, implying a center point origin.
My solution was to shift the origin to the center. Scale the mouse coordinates. Then, shift the origin back to the left corner.
You can read my full solution on here: http://michaellevyart.com/adjusting-mouse-position-svg-scale/
Michael
Just be wary that I think css transforms on svg elements in IE isn't very well supported, so I would do some extra testing in that browser if its a requirement to use IE (and using css transforms rather than svg transforms).
ibrierley, yes, current Web technology hasn't fully caught up with SVG in general. The biggest hurdles, I've faced are in mobile.
The dragging transforms, in this case (and probably in general, so it would be a better solution anyway just for drags), put the dragged translation first, ie..
this.transform( "t" + [ tdx, tdy ] + this.data('ot') );
rather than
this.transform( this.data('ot') + "t" + [ tdx, tdy ] );
On Mon, Jul 6, 2015 at 8:53 AM, Ole Henrik Skogstrøm < [email protected]> wrote:
What do you mean when you say "Swap the transforms around?". Can you give me an example? — Reply to this email directly or view it on GitHub #331 (comment) .
THANKS