Followup resize transformation: potential performance regression

[ollimeier]

potential performance regression with complex outlines

Just: I think we may have a bit of a performance problem with (very) complex outlines, as the relatively expensive getSelectionBounds() call is performed at every mouse move. I’m not yet sure what to do about it, maybe we need to followup with some optimizations. While the outline is not changing and while the selection is not changing, the getSelectionBounds() call will always return the same.

[ollimeier]

https://github.com/googlefonts/fontra/pull/1487#pullrequestreview-2142589832

From Just: Regarding, https://github.com/googlefonts/fontra/issues/1492, we actually have to address this here after all.

You call getSelectionBounds() as part of the draw code as well as on each mouse move. This is fundamentally too much computation for fast drawing, and does a lot of redundant work.

Instead, we should:

• subscribe to selection changes
• subscribe to glyph edits
• subscribe to change of edited-glyph

Then, use a throttled callback that will do the bounds computation, and store the computed bounds in a property of the scene model, and request a canvas update.

(Throttled: limit the number of callback calls per second, there's a helper func for that)

[ollimeier]

Further note from Just: We will separate:

• computation of the selection bounds
• using the selection bounds

Computation stores the current selection bounds in a scene model attribute. The rest of the code will use that attribute, unless it’s undefined.

[ollimeier]

The following page demos a great way of how we can analyze the performance: https://developer.chrome.com/docs/devtools/performance

There is a nice tool build into chrome which let's you slow down the CPU and record a profiling which give you hints if the performance is harming the user experience.