EdgeLayoutProcessor ignored during initial layout

[plglaser]

Description

When opening the diagram for the first time, the labels on edges are not properly laid out. Take the following model for example:

erdiagram Model

entity Ex1 { id key }
entity Ex2 { id key }

relationship Rel {
    Ex1[1] -> Ex2[ N | "roleeeeeeee" ]
}

The corresponding, invalid diagram is shown below (see Current Behavior and note the layout of the "longer" role for Ex2 in the relationship), right when opening the diagram initially.

After making changes to the model or refreshing the diagram, the automatic layout is fixed again and behaves as expected (see Expected Behavior).

Current Behavior

Invalid Layout:

Expected Behavior

Valid Layout:

Steps to Reproduce

1. Specify an ER model containing a "long" edge label (see Example)
2. Open the diagram
3. --> See incorrect Layout

Environment

Issue starts occurring in the recent releases (v0.2.0+) of bigER.

Additional Information

The problem seems related to the BigerEdgeLayoutPostprocessor, which is responsible for the layout of edge labels after model requests. In particular, it seems the client-server communication (of request model and layout model) is not working as expected. See Client-Server Protocol Documentation in the Sprotty Wiki.

I have looked and debugged several related components, however, I was not able to pinpoint the exact code location that is causing the issue yet. My hypothesis is that the issue is caused somewhere in the initialization process of the toolbar (see ERDiagramWidget) (e.g., through incorrect bindings).

[Aksem]

A bit more details: labels have width: 0 in bounds until changing/refreshing the diagram, half of the width is not compensated in the x-coordinate of labels, and as a result, they are in the wrong position. I'll investigate it further and provide more information.

[Aksem]

I've got it! The problem is that the boundaries of edge labels are not calculated on the initial loading. They are calculated only for elements that are rendered. And edge children are not rendered because the route length is 0 (see NotationEdgeView). The route length is 0 because LibavoidRouter skips routing if boundaries are not calculated yet(see LibavoidRouter.routeAll).

After boundaries calculation, edges are re-rendered again, and the route length is not 0 anymore, and this is exactly the moment when edge children(labels) appear in the diagram. But boundaries are not calculated for new elements, only after refreshing/changing the diagram.

I have no straightforward solution for this problem because I need to know the expected behavior in detail. I can propose the following options:

1. Render children of edges even if the edge route is 0.
2. Try to change LibavoidRouter so that boundaries are not required, and route edges always, even before boundaries calculation.
3. Activate boundaries calculation after adding new elements if possible.