fix: Don't render LoadingSpinner after it has faded out

[jviide]

This pull request attempts to reduce Wire's CPU usage when idle.

In the discussions related to issues #2507 and #2239 (and maybe elsewhere) @charlag et al. tracked down a culprit for some surpsingly high constant CPU load. The LoadingSpinner component is always rendered on top of the rest of the UI with 0 opacity after it has initially faded out, continuously using resources.

This pull request addresses the issue by hooking to the onTransitionEnd and onTransitionCanceled events and set a flag marking the fade out completed giving the fade out transition a fixed amount of time to finish. After this the component returns null, effectively removing the LoadingSpinner contents from the DOM tree.

Personally, I've noticed constant ~15% load when Wire was idling on my M1 MacBook Air. Launching Wire with devtools enabled and removing the spinner from the DOM drops the idle CPU usage to near zero. I couldn't get the build infra work 100% on my machine, so @ikisusi and @esatormi volunteered to test this patch on their Intel Macs, both getting similar results. @ikisusi's CPU activity monitor looked like this before applying the patch (and after the spinned had faded to 0 opacity):

And like this after applying the patch:

[CLAassistant]

All committers have signed the CLA.

[ffflorian]

Hi @jviide, thanks for the PR! I'll review it tomorrow.

[jviide]

I modified the approach. Instead of observing onTransitionEnd and onTransitionCancel events, the transition is given a fixed amount of time to finish after the isLoading flag flips from true to false. This happens regardless of whether the visible flag is on or off.

The length of this "transition grace period" is 500 ms by default to accommodate the current 250 ms transition.

I made this change after realizing that there may be situations when the transition events never get dispatched. For example, the user might switch accounts just right, making visible a webview that has already finished loading in the background. Then the transition from opacity 1 to 0 never happens.

[ffflorian]

Tested manually. Looks good!

[ffflorian]

Again thank you very much @jviide! I'll notify you as soon as the release including this PR is published.

[jviide]

Is there anything I could do to help get this change into production? The ability to squeeze a bit more battery life out of my laptop would be lovely :)

[bennycode]

Hi @jviide, your fix will go live with v3.27. We plan to ship this release early next week.

[marvinhagemeister]

@bennycode @ffflorian @Yserz I'm running into the same issue as @jviide and would greatly appreciate a new release. In its current state wireapp drains battery like crazy.

[bennycode]

Hi @marvinhagemeister, unfortunately our release got pushed back so it comes later than I anticipated. I am also not working at Wire anymore so my successor will take care of it.

[fluffypony]

Still waiting for this to go in, and for M1 support (Electron has had M1 support for well over a year).

[JMoVS]

@Yserz Is there any news when this might finally land on desktop on Macs? Desktop is still stuck at 3.26

[fluffypony]

This is crazy that it's taking months to go in - is this not something that can be part of a Wire Web update? I was under the impression those happen weekly, yet here we are nearly half a year later.

[embeddedt]

Can confirm that this is still an issue in January 2022 - after using the uBlock-based workaround suggested here, my CPU usage at idle is a lot less.

[jviide]

Seems that a version containing this PR has now been released to Mac App Store.