Rendering performance of QScrollArea

[thexeos]

What happened?

Changes to computed values (e.g., mouseenter leading to thumb display, scroll position change after pressing arrow keys with scrollable element in focus, thumb hide after timeout) used in QScrollArea component trigger re-render of the entire component stack housed within. While DOM manipulations don't occur after diffing, as no content changes are detected, all the render methods are nevertheless called.

What did you expect to happen?

I came around to investigating this after noticing an abnormal activity of vue-i18n using global fallback translation when rendering item lists. Scrolling in the list would trigger a lookup of local en-US translation, then local en translation, then move to looking up global en-US translation for every templated string (and in my case list items contain multiple such strings) resulting in hundreds and thousands of i18n invocations (and vue-i18n warning messages due to fallbacks happening) for a relatively short list.

Reproduction URL

https://jsfiddle.net/ycabj26f/

How to reproduce?

1. On the jsFiddle page, hover in and out of the scroll area, try scrolling using mouse wheel or arrow keys (after focusing the scroll area)
2. Notice the log entries being added
3. Also notice that upon initial opening of the page, three recomputes were performed

Additional context

Quick inspection of QScrollArea and the compiled render function reveals this behavior as "expected".

Since all the computed value updates relate to thumb display, the straight forward solution would be to pull out the thumb rendering logic into pure JS world. I also suspect there is a way to rewrite the render function (rather than relying on the compiler) using vnode creation calls to mark the child nodes (ones inserted via the slot) as isolated from thumb-related nodes.

Known workaround

For those that are seeking a workaround, you can use v-memo or v-once on your components rendered within QScrollArea. But make sure you understand how they behave, before using them in production.

[pdanpdan]

duplicate of #16579