[POC] Experiment BPMN diagram navigation with CSS Transforms

[tbouffard]

DISCLAIMER: This is a POC it is not intended to be merged. Tests can fail, SonarCloud complains and force-push can occur at any time

TODO description in progress

Rationale

By default, mxGraph manages pan and zoom/fit by recomputing and rendering the graph again (this involves DOM manipulation). This has bad performances and decreases the User Experience.
See maxGraph/maxGraph#2 (comment), jgraph/mxgraph#204 or jgraph/mxgraph#265
Notice that if the container used to display the graph has scrollbars, the pan is managed by default by using the scroll bars, which is cheap.

As part of the support of the "zoom with the mouse wheel" in bpmn-visualization, we have been forced to do throttle/debounce to limit lags, but lags can occur when using the zoom API (currently, there is no throttle/debounce on it). Others like draw.io, the mxGraph graphEditor example used the same technique with features called fastZoomEnabled or lazyZoomEnabled.
However, if this solution avoids lags, the zoom experience isn't smooth. There is a delay between mouse wheel scroll and the actual application of the new scale, especially because of the denounce.

In addition, if updates are done on the DOM elements related to the diagrams prior navigation, they are removed after navigation. This limits a lot the customization that can be done outside bpmn-visualization.
We introduced the CSS API not only to help people applying CSS classes (we hide selectors) but also to ensure the classes remained applied when mxGraph redo rendering.
However, this doesn't cover all use cases. For instance

• if the CSS class defines an animation that is supposed to run only when the class is applied, it is replayed on zoom/pan because of the new rendering.
• if custom code modify SVG to update the aspect of a cell directly in JS code, it is dropped after the new rendering

I also recently see warnings in the DevTools console with Chrome 104.0.5112.101 (Official build) (64 bits) or Brave 1.42.97 Chromium: 104.0.5112.102 (Official build) (64 bits)
With reference file B.2.0, at load time (whatever the fit type is), when zooming, doing fit or panning

• at load time

[Violation] 'load' handler took 436ms main.js:52 
[Violation] Forced reflow while executing JavaScript took 129ms

• other cases

[Violation] 'click' handler took 349ms index.js:1 
[Violation] 'pointerup' handler took 288ms mxgraph.js:3

Solution experimented here

Instead of doing new rendering, the zoom/fit and move should rely on the transform attribute to manage the scaling and the translation of the graph. This delegates all navigation operations to the browser as this is generally done in diagramming and rendering solutions.

In draw.io and in the mxGraph graphEditor examples, there is a useCssTransforms property in the Graph prototype (which inherits from the mxGraph prototype).

https://github.com/jgraph/mxgraph/blob/v4.2.2/javascript/examples/grapheditor/www/js/Graph.js#L1647-L1660

<-- I thought that a code snippet will be displayed with a specific commit but it doesn't work
https://github.com/jgraph/mxgraph/blob/273779f744f4ff9012847a423bbb620839da58bb/javascript/examples/grapheditor/www/js/Graph.js#L1647-L1660
-->

There are also a bunch of code (function prototype redefinition mainly in mxGraph and mxGraphView) to change the xxx. to continue....

Implementation done here

I have integrated the [email protected] and [email protected] code related to useCssTransforms.
Then

• add custom implementation to make the pan work. The draw.io/mxgraph code only works with a container with scrollbar
• update the implementation of the zoom for mouse wheel when using CSS transforms

The code can still managed the zoom and pan as curently done in the bpmn-visualization release.
It could be possible to make the usage of CSS transforms an option for evaluation.

1st results

With B.2.0,

• very smooth zoom
• Fit Center operation: 10 to 30 ms instead of 250-350 ms in v0.26.0. Check with console logs of the demo, this is not a performance test, but it gives direction. Visually, this is faster
• the violation warnings only occur at load time

Possible next steps

Run performance tests to have more insights
The e2e tests for the BPMN rendering fail: the differences seem coming for the scaling computation (may be a rounding issue)
Investigate what is happening when adding overlays (see xxxx)
Review the value of the zoomFactor that may not be accurate for CSS transforms. We may need to make it configurable at initialization and/or at runtime.

[github-actions]

🎊 PR Preview 1718816 has been successfully built and deployed to https://process-analytics-bpmn-visualization-js-demo_preview-pr-2199.surge.sh

🕐 Build time: 20.112s

_{🤖 By surge-preview}

[github-actions]

🎊 PR Preview 1718816 has been successfully built and deployed to https://process-analytics-bpmn-visualization-js-doc_preview-pr-2199.surge.sh

🕐 Build time: 13.066s

_{🤖 By surge-preview}

[tbouffard]

B.2.0 navigation examples

v0.26.0

B.2.0-navigation_v0.26.0.mp4

commit 150a01d

B.2.0-navigation_PR_2199_commit_150a01d.mp4

[tbouffard]

✔️ External DOM modifications are not dropped anymore.
This allows a lot of new use cases and extension with custom code.

v0.26.0

Modifications are dropped after pan (or zoom or fit)

external_DOM_update_v0.26.0-2022-08-26_17.09.25.mp4

commit 1718816

Modifications are kept after navigation

external_DOM_update_PR_2199_commit_1718816e150a01d-2022-08-26_17.03.40.mp4

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
22 Code Smells

43.6% Coverage
0.0% Duplication