pan_to_point locking up svg

[MadTooler]

Howdy!

The SVG node has been very useful in my projects. Thank you for the hard work!

I am trying to zoom into a path within the SVG and show a cursor following along it (my intent is a GRBL sender within Node-red and this is for a 2d visualizer window). I was thinking the pan_to_point via payload may be helpful, but anytime I send the command, other than to an xy point of 0, it seems to lock up the SVG. I have been using the example with my xy to 50,50 since my SVG is set to 100 x 100.

[
    {
         "command": "pan_to_point",
         "x": 50,
         "y": 50
    }
]

Zoom seems to work ok, although I do not understand how it uses xy coordinates in the zoom to point method. The point does not seem to be absolute.

Edit: The reset_panzoom works as expected. It also will fix the SVG to undo whatever the pan_to_point did to it.

Any known issues here?

Thanks.

[bartbutenaers]

Hi @MadTooler,

Could you please explain with e.g. the following example flow what goes wrong:

1. I import the pan zoom demo flow via the Import menu item in the Node-RED flow editor:

   

2. When I press this Inject button:

   

3. Then my SVG drawing indeed is panned with the specified distances:

   

   I measured it via the mouse-coordinates Chrome extension.

But I assume you mean something different?

Bart

[MadTooler]

Thanks for getting back to me @bartbutenaers

Hi @MadTooler,

Could you please explain with e.g. the following example flow what goes wrong:

1. I import the pan zoom demo flow via the Import menu item in the Node-RED flow editor:
2. When I press this Inject button:

The example did work. I also tried your inject on my current svg and it also worked. The difference I see is your json message does not have [ ]. When you add the brackets around the { } message, as when multiple commands are to be sent, it will freeze the svg. I found zoom commands and reset commands all work inside brackets, sometimes even when accompanied by the pan command in the same brackets, but any time there is a pan within brackets it will freeze. Sending a new zoom, reset, or even a pan without [ ] will unfreeze the svg.

3. Then my SVG drawing indeed is panned with the specified distances:

Regarding how the pan to point is intended to function, I had assumed the coordinate of the "absolute" point within the svg itself would be panned to the center of the svg widget view (which is what I am trying to achieve). It appears to me that it pans the origin point of the svg to the point instead (sort of). Working with that approach, I tried to pan the svg to a new point in an attempt to center an svg element in the view.

Unfortunately, it appears the pixel movements are browser window based instead of svg element based. Meaning, if I tell it to pan to point 100,100 it moves 100,100 pixels in the browser window instead of relative to the pixels declared in the envelope of the svg.

For example, my projects working svg window is 100x100 and smashed into a widget dashboard grid size of 9x9. If I pan a point of 50,50, the result is not the upper left corner of the svg now being in the center of the view, but only about 1/4 of the way there. I find I need to multiply my offsets by around 4.6, meaning an offset of 230,230, to get a close enough result. My dashboard widget size, spacing, and padding are part of that multiplier, but I have yet to find a full equation of those values that equals the 4.6 ratio I determined, first through testing, then through using the mouse coordinate extension to verify. This also makes it messy that I would have to change my multiplier every time I tweak my dashboard widget size (there probably is a fancy way to keep that formula driven for someone better than myself).

I measured it via the mouse-coordinates Chrome extension.

FYI... this chrome extension didn't function at first in chrome. Others noted similar issues where it only outputs the initial value near where the extension button is pressed in the toolbar. It automagically started working after a while. Restarting chrome didn't immediately seem to be the solution. Maybe some anti-virus checking was at play.?

But I assume you mean something different?

Bart

[MadTooler]

@bartbutenaers This seems to be functioning as long as I only send one command at a time. I would think this can be closed.

Thanks!