feat: re-measure overflow without forced .update(true)

[Menci]

This is a follow-up for #729.

.update(true) is very slow. From the performance tool in DevTools. the heavy path is: update -> ... -> getElementOverflow -> getStyles -> "anonymousCallbackTo: from(styles).deduce" -> getCSSVal -> "Recalculate style".

To solve this, I introduced the option .update({ measureOverflow: true }) to trigger an measurement update bypassing the heavy forced-update logic.

[Menci]

BTW, I think overflow behavior shouldn't be inferred from getComputedStyle(). This should, or at least should allow to, be provided in options. getComputedStyle() is so heavy that sometimes eats ~3 frames on my computer.

[KingSora]

Good day @Menci :)

Thank you very much for taking the time to create a PR! I would really like to keep the current update functionality (e.g. passing just a force?: boolean as a param). The reason for that is its simplicity and it also doesn't bound the library to support specific update paradigms.

I've recently released v2.13.0 of OverlayScrollbars where the options.update.debounce option was reworked and now allows a more granular configuration of debounces. This should make your strategy you posted here viable.

BTW, I think overflow behavior shouldn't be inferred from getComputedStyle(). This should, or at least should allow to, be provided in options. getComputedStyle() is so heavy that sometimes eats ~3 frames on my computer.

I'm getting the overflow style to determine whether I can skip all of the needed calculations which are needed for the overflow. For those I'm also using potentialy heavy properties / functions such as scrollWidth / scrollHeight and getBoundingClientRect(). Besides that its also used for the options.scrollbars.visibility option.

[Menci]

I'm getting the overflow style to determine whether I can skip all of the needed calculations which are needed for the overflow. Besides that its also used for the options.scrollbars.visibility option.

I think getComputedStyle() is much more expensive than all the calculations.

[Menci]

Updating via events also trigger getComputedStyle(). This PR introduces the way without getComputedStyle().

[KingSora]

@Menci I've added a new option called update.flowDirectionStyles which can be used to customize this behavior.. You could pre-compute those values once for example and re-use the values for future updates, or return empty styles to opt-out of the "non default flow direction" check entirely if thats not relevant for your usecase.

You can test it out with the new v2.14.0 release :)

[Menci]

Thank you! I'll check it later.