Spreed: High energy impact when Talk tab is visible, none when invisible

[PVince81]

Steps to reproduce

1. Open Talk app in a first Firefox window
2. Create a few rooms with multiple people
3. Refresh the page
4. Open a second Firefox window and open "about:performance" in it, highlight the entry for the Talk app and observe: sustained medium impact
5. In the first window, create a new empty tab and switch to it, this makes the Talk tab invisible: low impact
6. Switch back to the Talk tab: sustained medium impact again

Note: if the medium impact doesn't happen, try switching between multiple rooms, then observe again.

Expected behaviour

Low performance impact when no poll request is happening.

Actual behaviour

Medium performance impact despite no network requests happening.

Talk app

Talk app version: 10.0.0 (on NC's company cloud) and 11.0 pre-alpha on git (a9fb5baf41227d5ff71dad7e134dbb4875a05503)

Custom Signaling server configured: yes for NC cloud, no for local one.

Notes

This is important nowadays because people might leave a Talk window present on another monitor like I do, or another virtual desktop (on Linux)

I tried the performance graph tool from Firefox but could not yet found anything significant apart from some GC triggers.

[PVince81]

Doesn't happen when loading Talk without entering a room.
It's once a room has been entered that it happens.

I had one rare case where I first joined an existing 1-1 room and the impact was still low. Then after switching between rooms and coming back it went up to medium again.

I've tried hiding all visible elements with "display:none" but the impact is still there: so it's not a rendering issue.

[PVince81]

Perf debugger when tab is active:

Sadly most is empty space.

And here when the tab is unfocussed:

If I comment out the "ChatView" in "MainView" so it doesn't get rendered, the problem disappears.
So it's not only about hiding visually but also the absence of matching DOM elements.

[PVince81]

removing NewMessageForm solves the problem... getting closer...

[PVince81]

EmojiPicker :question: :exclamation: :boom: :exploding_head: :fire:

[PVince81]

Deleting the DOM nodes of the EmojiPicker in the inspector did not solve the issue.
So it must be in the popup itself.

I've checked the EmojiPicker in the Vue style guide here https://nextcloud-vue-components.netlify.app/#/Components/EmojiPicker and despite its presence the performance impact is not observed there.

So it must be something specific to the layout here in Talk

[PVince81]

I went up to EmojiPicker.vue and the problem disappeared if I removed the Picker element.
Removing only the CSS (including the import from the lib) in EmojiPicker.vue didn't help.

The Picker belongs to the library https://github.com/serebrov/emoji-mart-vue

[PVince81]

Updating to the latest version (7.0.7) did not help.

If I replace "Picker" with "StaticPicker" in nextcloud-vue, the performance problem disappears.

I saw that "Picker" is using "DynamicScroller" aka virtual scrolling, and maybe somehow that bit is doing something in the background... or causing those repeated GC events, even though nothing is rendered yet.

Visually, the static picker looks the same and also has a search box.
If we don't find a better solution I suggest we simply make that switch.

Also see https://github.com/serebrov/emoji-mart-vue/issues/80

@skjnldsv @ma12-co

[PVince81]

PR here: https://github.com/nextcloud/nextcloud-vue/pull/1526

[jospoortvliet]

great research @PVince81 !

[PVince81]

• [x] Update nextcloud-vue for master: https://github.com/nextcloud/spreed/pull/4513
• [x] Update nextcloud-vue for stable20: https://github.com/nextcloud/spreed/pull/4514