Reduce CPU in browser when tab is not visible

[blammit]

Relevant thread with Mathijs:

The main two things:

• disconnect from mqtt
• stop moving ants animation

Note that browser tab not being active is not the same as browser tab not visible.

Which happens because browsers are getting smart: tabs that use a lot of CPU while not visible to the user are getting punished by them to reducing allowed number of CPU cycles (or function calls or however they to it) to a minimum.

Note: Talk to Alex & co working on VRM Portal and see how they are solving these issues.

If this appears to be impossible from WASM/Qt, then we can do it from html/javascript as well: unload WASM if tab is invisible for 30 seconds (or some other number of seconds) and reload when visible again.

[chriadam]

Some quick investigation: top level Window onVisibleChanged does not get triggered when making other tabs active, nor does onActiveChanged nor onActiveFocusItemChanged. So, it might be tricky from Qt side to get the tab active status.

We might be able to hook into events directly at emscripten level. See https://www.w3.org/TR/page-visibility/ and https://github.com/emscripten-core/emscripten/blob/main/test/test_html5_core.c for the example (check visibilitychange handler).

[chriadam]

There are a variety of animationEnabled properties. Tomorrow I will investigate how many of those will need to have their bindings updated to include some Global.animationEnabled lookup. It's possible that only a few will be (e.g. properties in the root of OverviewWidget.qml and BriefPage.qml etc), but it's also possible that many of them will need to be updated. Then, I will add callback handlers for visibilitychange and update the Global singleton's animationEnabled property accordingly.

That should get us most of the way there. I'm trying to think what else might take up CPU time after all of the animations are stopped, but not much is coming to mind (timers in the fps visualizer, but they can be disabled when visible is false, also... anything else?)

[chriadam]

The above PR was merged, which suspends animations and timers while the tab is not visible. In future, if necessary, we could also throttle MQTT message handling, for example, but it isn't yet certain whether it is necessary. MDN docs say that tabs which use WebSockets are not throttled in the same way as other tabs, for example.

Matthijs has advised us that this task should be considered lower priority for now.

[chriadam]

A variety of PRs should also help to address this: https://github.com/victronenergy/gui-v2/pull/515 https://github.com/victronenergy/gui-v2/pull/507 https://github.com/victronenergy/gui-v2/pull/503 https://github.com/victronenergy/gui-v2/pull/502

have been merged already, and we have future PRs: https://github.com/victronenergy/gui-v2/pull/501 https://github.com/victronenergy/gui-v2/pull/470

and potentially also: https://github.com/victronenergy/gui-v2/pull/517

Adding to 1.0.0 milestone. But the PRs are more about device performance rather than web performance.

[chriadam]

Some work in this area has been done already, see the listed PRs above. However, those aren't webassembly specific (e.g. in general we need to reduce CPU usage on all screens, regardless of platform), but this task tracks webassembly-specific changes which are needed to reduce tab CPU usage. I suspect we might need to do things like e.g. stop animations after some time, rather than letting them continue to play.

We will look into this once the other issues are resolved. Considering it low priority for now.

[jpetrell]

What is still missing here? Seems the issue described in the title has been solved already? Nothing has happened here in months, maybe close this one and file remaining issues as separate items.

[chriadam]

I agree. Closing. One possibility: we could detect when tab is inactive, and use that to pause electron animations, for example.

[mpvader]

hi, reopening this to make sure its on the agenda for v1.1.0. I'm not 100% sure if something needs to be implemented here - first need a short discussion with Wiebe, and maybe VRM team to make clear if something needs doing / what needs doing and perhaps sending a signal from VRM to gui-v2 might help as well.

But - this is not a priority for now