One graph, two papers, manhattan routing - different results on two papers

This issue has been tracked since 2022-05-12.

So I have two papers and one graph. One paper is large and shows the portion of the page, and is scrollable. The other paper is smaller and shows the entire page zoomed out. This is a typical scenario to display the entire page view on the right-hand side, and I have seen it in the joint.js tutorials here: https://resources.jointjs.com/tutorial/multiple-papers

The problem is, when I use manhattan routing, the results differ on the papers. The larger one has different renderings of the links than the smaller one. I am guessing this is because one of the papers (perhaps the larger one) does not fit in the allotted (default: 2000) iterations for the manhattan algorithm and falls back into the orthogonal, as it's described by the documentation. If that is the case, I'd expect that both the papers would do the same, but perhaps there is some dependency on the paper size in the manhattan algorithm.

So my goal is to have the same results on both papers. What do you suggest I do?

kumilingus wrote this answer on 2022-05-13

As far as I know the manhattan router is independent from the paper's current scale and size and looking at the code I can't find any dependency. It operates in the graph's coordinate system (i.e without transformations).

Could you try to update this example to reproduce the issue?
https://jsfiddle.net/kumilingus/87Lut2sx/

ttutisani wrote this answer on 2022-05-13

I can't reproduce it on that jsfiddle. The thing is, my elements are more complex, they have image, icon, nested shapes, etc. I think something does not scale down and hence the issue.

I was able to find one issue already. Basically, my element has a nested rect, which on the full size was not an issue. But on the smaller scale it was out of the element's boundary and that was causing the anchor to move perhaps on the small size. I changed the inner rect's coordinates to be closer to the center (it was on the side) and that fixed some issues. (if you need more info on this issue, let me know)

But the issue persists in other cases, and I need to play with it to find out which exact case that is.

kumilingus wrote this answer on 2022-05-13

I can't reproduce it on that jsfiddle. The thing is, my elements are more complex, they have image, icon, nested shapes, etc. I think something does not scale down and hence the issue.

It should not matter how complex your shapes are. You should try to replace your elements with simple ones in your application and see if the issue persists (or update JSFiddle with your shapes).

What do you mean by "nested" shapes? You mean that the shape of yours consist of multiple SVG elements or are you using embedding feature?

I was able to find one issue already. Basically, my element has a nested rect, which on the full size was not an issue. But on the smaller scale it was out of the element's boundary and that was causing the anchor to move perhaps on the small size I changed the inner rect's coordinates to be closer to the center (it was on the side) and that fixed some issues. (if you need more info on this issue, let me know)

I do need more info on this.

How exactly did you define your shape? It would require a custom view to create a shape that looks different at a different zoom level.

ttutisani wrote this answer on 2022-05-13

All right, I was able to reproduce: https://jsfiddle.net/eL6rma07/

Just open that jsfiddle. Don't move things around. It should be showing the difference immediately. It shows for me (see below image). Thoughts?

image

kumilingus wrote this answer on 2022-05-13

I don't see this problem on my computer, so I can only assume it has to do with how the element is defined.

I have updated the demo: https://jsfiddle.net/kumilingus/eh460qcg/

Are you still experiencing this problem?

ttutisani wrote this answer on 2022-05-13

Wow, I didn't know about the magnetSelector. The jsfiddle looks good now. Thanks!

I will try to apply the same technique to the app and see if that helps.

ttutisani wrote this answer on 2022-05-13

Yay, it worked perfectly! Both the papers now show the same results. Thanks for your help!

kumilingus wrote this answer on 2022-05-14

I'm glad it worked out.
It could have been a problem with fonts not yet loaded. The size of the <text> element changed after they were loaded.
I am closing the issue now. Feel free to reopen if it comes back.

More Details About Repo
Owner Name clientIO
Repo Name joint
Full Name clientIO/joint
Language JavaScript
Created Date 2009-09-11
Updated Date 2022-12-06
Star Count 3717
Watcher Count 155
Fork Count 817
Issue Count 53

YOU MAY BE INTERESTED

Issue Title Created Date Updated Date