fix: debounce minimap rendering

[Skaiir]

Closes #81
Related to #96

Proposed Changes

This adds two configs debounceDelay and debounceSkipDelay, which prevent updates from running frequently when many update triggering actions are fired consecutively. In practice this means any updates fired within debounceDelay ms are fired off as a single update at the end UNLESS debounceSkipDelay is reached, which triggers an update regardless to allow for very long running renders to still display a somewhat current mini-map. Note this does not apply to user interactions with the minimap, as debouncing interferes with the viewport visuals (I haven't figured out a good way to handle this yet).

Secondly, while the minimap is closed, we simply do not update it. However we always force a non-debounced update on open (to ensure viewport information is properly initialized).

Checklist

To ensure you provided everything we need to look at your PR:

• Brief textual description of the changes present
• Visual demo attached - Can't really display much, but this cuts down the rendering time of 2000 elements in the process landscape from over 5 minutes to under 1.
• Steps to try out present, i.e. using the @bpmn-io/sr tool
• Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

[nikku]

@Skaiir Let's please have a test case for the "extreme setup" that we're targeting. I'd love to ensure this is properly tested.

[Skaiir]

@nikku I've set something up quickly but because it's asynchronous I wasn't able to turn it into a proper unit test. Maybe I need to make it a little less intense though because at 3000+ items it looks like diagram-js starts falling apart.

Edit:

What do you think of this, we have this asynchronous observable extreme extreme case test which we keep as a .skip for dev testing ad-hoc, and we add another slightly less insane synchronous test (no yielding back to the browser, so it will freeze for a while) and expect a maximum execution time. I think if I keep the number of elements drawn around 1500-2000 it's somewhat within 5-10 seconds execution time with the current perf.

[nikku]

What do you think of this, we have this asynchronous observable extreme extreme case test which we keep as a .skip for dev testing ad-hoc, and we add another slightly less insane synchronous test (no yielding back to the browser, so it will freeze for a while) and expect a maximum execution time.

I'd ensure that the minimap does not actually block things, i.e. continuing to model works.

I think if I keep the number of elements drawn around 1500-2000 it's somewhat within 5-10 seconds execution time with the current perf.

Yes, that could be feasible.