8000 Subflows with MRTREE algorithm - incorrect position and width calculation · Issue #294 · kieler/elkjs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Subflows with MRTREE algorithm - incorrect position and width calculation #294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails 8000 .

Already on GitHub? Sign in to your account

Closed
belamajoros opened this issue Aug 1, 2024 · 7 comments
Labels

Comments

@belamajoros
Copy link

Hi, when using the mrtree algorithm with subflows, the position of the nodes inside of the subflow is incorrectly calculated. Also in case of a subflow inside a subflow, the width of the parent subflow is also incorrectly calculated and part of the child subflow gets placed outside of its parent subflow.

example for elklive:
{
id: "root",
layoutOptions: {
'algorithm': 'mrtree',
'elk.direction': 'DOWN',
'elk.spacing.nodeNode': '50',
},
children: [
{ id: "n1", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP'} },
{ id: "n2", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP'} },
{ id: "n3", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP', 'elk.algorithm': 'mrtree', 'elk.direction': 'DOWN'}, children: [
{ id: "n7", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP' }},
{ id: "n8", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP'}}
]},
{ id: "n4", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP'} },
{ id: "n6", width: 30, height: 30, layoutOptions: { 'elk.alignment': 'TOP'} }
],
edges: [
{ id: "e1", sources: [ "n1" ], targets: [ "n2" ] },
{ id: "e4", sources: [ "n1" ], targets: [ "n3" ] },
{ id: "e3", sources: [ "n2" ], targets: [ "n4" ] },
{ id: "e5", sources: [ "n1" ], targets: [ "n6" ] },
]
}

Screenshots
image
image

This in itself would not be a huge problem as I am able to correctly position the nodes inside the subflow after calling elk.layout().

Regarding the incorrect parent subflow width:

Screenshots
If the subflow is on the right side of the branch (incorrect):
image
If the subflow is on the left side of the branch (correct):
image

ELK Version
0.9.3
algorithm: mrtree

@belamajoros belamajoros added the bug label Aug 1, 2024
@Eddykasp
Copy link
Collaborator
Eddykasp commented Aug 1, 2024

This is indeed a bug, minimally reproduced in this example. The problem seems to be in the position and size calculation of the graph after layout.

@seloElo
Copy link
seloElo commented Apr 25, 2025

Thanks for the issue raising on github you saved me an headache on my graphs...
Was this fixed on elk 0.10 but not packaged in the js package?

@Eddykasp
Copy link
Collaborator

It should also be fixed in elkjs 0.10.0. If it's not I'll have to look into whether there is a separate issue or whether something went wrong during transpilation. Do you have an example that is broken?

@seloElo
Copy link
seloElo commented Apr 28, 2025

Used the example of react-flow let me know if this not okay.

https://stackblitz.com/edit/xfsrw92e?file=App.tsx

Image

Same example if I use layered, we can see that the weird padding is not there:

Image

@Eddykasp
Copy link
Collaborator

There is definitely something wrong somewhere, I'm investigating this and will keep you updated

@Eddykasp
Copy link
Collaborator

I can now confirm that it is broken in elkjs 0.10.0, but the behaviour is different to the bug in 0.9.3. I need to reconfirm that Java ELK 0.10.0 behaves correctly and then hopefully I can figure out what is causing the discrepancy.

@Eddykasp
Copy link
Collaborator
Eddykasp commented May 6, 2025

I've created a PR (eclipse-elk/elk#1142) that should fix this issue. It was caused by separated components i.e. multiple tree layouts. They are layouted individually and then put back together. In this step, the bounds of the packed graph was not recomputed but rather the bounds of the components were merged, causing the described issue in the result.

@Eddykasp Eddykasp closed this as completed May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
0