Playing Icon consumes a lot of CPU

[giantorth]

Describe the bug
The playing icon for the active track (animated green bars) consumes a noticeable amount of CPU when visible in a browser.
The older mac consumed 60% of the cpu and the newer windows machine required 10% of the cpu to display this graphic.

To Reproduce
Tested on a Mid 2014 MacBook Pro and an 8th gen Core i7 windows 10 machine, both using latest chrome.

Expected behavior
Animated icon should not consume that much resources.

Console log
N/A

Screenshots
N/A

Environment details:

• OS: Mac/Windows
• Browser: Chrome
• Iris version 3.58.0

Additional context
Bars appear to be animated using CSS/JS. An animated gif would use much less resources.

[jaedb]

This is really interesting. I have been curious to improve the browser app performance of Iris so that it can run more smoothly on lower-powered devices (like a Rpi for instance).

How did you determine that the animation was the cause of CPU usage? What was your testing routine? I'm keen to reproduce your results to explore the options in more depth.

[giantorth]

The discovery was somewhat by accident, I was using VNC to access a machine remotely and was wondering what the source of the mouse lag was.

Testing is pretty rudimentary, open task manager and navigate between the now playing or the search page. On an 11th gen i7 machine, chrome (or firefox actually) uses about ~1% on the search screen and ~5% on the now playing screen along with 10-12% of the GPU. The effect seems to be greatly exaggerated the less powerful the machine is too. If you pause the music you can immediately see the resource usage drop as well, despite the computer not actually being involved in any audio playback directly.

When I suspected it could be that animated green bar icon I did some digging with the browsers dev console. Inspecting the element showed that it was animated by using JS/CSS to change the size of the elements rapidly instead of using a multi-frame gif image. I suspect the code driving this animation has much more overhead than expected.

[jaedb]

Thanks for that info, I'll have a crack at replicating it and removing to animation to compare performance. I did have an initial trial (by just removing the element entirely) with no noted change. I had creates this using CSS transitions, which are designed to be performant and use the GPU (separate thread?) instead.

One factor to consider is one element that I DO know is heavy: parallax. This is used on the artist and now playing screens.

Did you, per chance, happen to compare usage with the artist page? While the parallax also uses GPU and transform techniques, it does also use bur, which can be particularly demanding.

[giantorth]

I finally got around to checking the other pages, and yes the artist page consumes nearly 50% cpu on this older macbook.

[chatziko]

I can confirm this issue. Here's a quick and dirty benchmark, on a Linux machine (only the browser runs in this machine, mopidy runs in a separate server):

Now playing page, Firefox:

• With music paused: ~10% CPU
• With music playing: ~45% CPU
• With music playing and green bars hidden: ~22% CPU
  (achieved by removing the js--playing icon--playing class from the <i> tag containing the green bars)

Now playing page, Chrome:

• With music paused: ~6% CPU
• With music playing: ~35% CPU
• With music playing and green bars hidden: ~10% CPU

Maybe the GPU acceleration is not working on my machine?

In any case I'd certainly prefer an animated gif, it's a huge difference for such a tiny UI detail.

[chatziko]

Interestingly, I just noticed that spotify's own web UI simply uses the following animated gif for the "green bars" 😄

https://open.scdn.co/cdn/images/equaliser-animated-green.f93a2ef4.gif

[curiousercreative]

@jaedb I've been having intermittent issues with my laptop for the past several weeks that I've finally tracked down to CPU & GPU usage in Iris, specifically I've noticed on the Now Playing and Artist page (Spotify only?), but only when a track is playing.

My system specs:

• i7-1167g7 quad-core CPU
• 32GB RAM
• NVIDIA 1650 Ti dGPU (effects observed on iGPU as well though)
• Pop!_OS 22.04 (Ubuntu derivative)
• Chromium 115.0.5790.170
• Iris 3.67.0

Reproduction steps:

1. Queue any tracks and start playing (tested with Spotify and Bandcamp tracks)
2. Observe CPU & GPU for 30 seconds (in a terminal window, run a recent version of nvtop for example)
   ER/AR: CPU & GPU usage is minimal, <5%
3. Navigate to the now playing page (/iris/queue) and observe CPU & GPU usage for 30 seconds
   ER: CPU & GPU usage should remain minimal, <5%
   AR: CPU usage for Iris Chromium process jumps to 33% and overall system usage jumps to 55%
   AR: GPU usage for Iris Chromium process jumps to 60% and overall system usage jumps to 80%
4. While on the now playing page, pause playback and observe CPU & GPU usage for 30 seconds
   ER/AR: CPU & GPU usage is minimal, <5%

[curiousercreative]

Just with some quick tinkering in a web inspector, I can confirm the parallax doesn't seem to matter much, it's the CSS animation on the playing bars that seems to be responsible for the usage. Initially I found that the animation was layered with the parallax and thought that might be the cause, but removing the parallax layer entirely doesn't seem to change any and I didn't find any good reason for that CSS animation to result in such load.

Spotify's web player uses this animated GIF when the window is focused and replaces it with a static image when the page loses focus. With the Spotify player active and focused, Spotify process CPU usage is about 10% while GPU usage is < 5%.