[GH-ISSUE #481] CPU maxed while song playing and tab is in focus #341

Closed
opened 2026-02-26 02:32:54 +03:00 by kerem · 12 comments
Owner

Originally created by @Porco-Rosso on GitHub (Nov 12, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/481

Hey, thanks for contributing to Koel! To save time for both of us, please make sure these checkboxes are checked before submitting the issue:

  • You have read and followed closely the Wiki, Upgrade Guide, as well as Troubleshooting
  • The issue has not been reported before
  • This is not a "how to install on Windows" or "why is my npm messed up" question
  • You're a cool person

All checked? Now also make sure your issue

  • Is associated with a version. Or better yet, a commit.
  • Is as detailed as possible (ahem... OS, browser, steps to reproduce, maybe?)
  • [] Includes the error output if it's a bug/error report ("Whoops!" is not very helpful, you know)
  • Is in English, 因为我不说中文。

So I recently reinstalled Koel from scratch. This seemed to have fixed the errors I had before.

However something that has been constant across all browsers and versions of Koel has been the high cpu usage while the tab is in focus. Any time I have the tab open, and am playing a song my CPU gets pinned at 60%-100%.

Nothing is displayed in the console, but doing my best to inspect, it seems to be something connected with the GPU and "update layer tree" being constantly called. My bets is on something connected to updating the player progress.
Any help on this would be appreciated.

Originally created by @Porco-Rosso on GitHub (Nov 12, 2016). Original GitHub issue: https://github.com/koel/koel/issues/481 Hey, thanks for contributing to Koel! To save time for both of us, please make sure these checkboxes are checked before submitting the issue: - [x] You have read and followed closely the [Wiki](https://github.com/phanan/koel/wiki), [Upgrade Guide](https://github.com/phanan/koel/releases), as well as [Troubleshooting](https://github.com/phanan/koel/wiki/Troubleshooting) - [x] The issue has not been reported before - [x] This is not a "how to install on Windows" or "why is my npm messed up" question - [x] You're a cool person All checked? Now also make sure your issue - [x] Is associated with a version. Or better yet, a commit. - [x] Is as detailed as possible (ahem... OS, browser, steps to reproduce, maybe?) - [] Includes the error output if it's a bug/error report ("Whoops!" is not very helpful, you know) - [x] Is in English, 因为我不说中文。 So I recently reinstalled Koel from scratch. This seemed to have fixed the errors I had before. However something that has been constant across all browsers and versions of Koel has been the high cpu usage while the tab is in focus. Any time I have the tab open, and am playing a song my CPU gets pinned at 60%-100%. Nothing is displayed in the console, but doing my best to inspect, it seems to be something connected with the GPU and "update layer tree" being constantly called. My bets is on something connected to updating the player progress. Any help on this would be appreciated.
kerem closed this issue 2026-02-26 02:32:54 +03:00
Author
Owner

@phanan commented on GitHub (Nov 14, 2016):

Can you share how long it takes to max the CPU? How many songs, roughly? Thanks.

<!-- gh-comment-id:260248352 --> @phanan commented on GitHub (Nov 14, 2016): Can you share how long it takes to max the CPU? How many songs, roughly? Thanks.
Author
Owner

@Porco-Rosso commented on GitHub (Nov 14, 2016):

It happens from the first song, within I would say 10-20 seconds.
Looking more carefully, CPU usage from the browser hovers around 60% (on my ~2015 Macbook Pro) while tab is in focus, dropping to less than 10% when the tab is not in focus. And less than 3% when koel is not open.
Other music sites such as spotify or soundcloud don't tend to have anywhere near this impact, so I doubt it has anything to do with audio playback

<!-- gh-comment-id:260411971 --> @Porco-Rosso commented on GitHub (Nov 14, 2016): It happens from the first song, within I would say 10-20 seconds. Looking more carefully, CPU usage from the browser hovers around 60% (on my ~2015 Macbook Pro) while tab is in focus, dropping to less than 10% when the tab is not in focus. And less than 3% when koel is not open. Other music sites such as spotify or soundcloud don't tend to have anywhere near this impact, so I doubt it has anything to do with audio playback
Author
Owner

@phanan commented on GitHub (Nov 15, 2016):

I'm not familiar with this problem tbh – never heard or seen before. What
browser/version, and not less important, do you have any funny addons
installed?

On Tue, Nov 15, 2016 at 2:04 AM, Porco-Rosso notifications@github.com
wrote:

It happens from the first song, within I would say 10-20 seconds.
Looking more carefully, CPU usage from the browser hovers around 60% (on
my ~2015 Macbook Pro) while tab is in focus, dropping to less than 10% when
the tab is not in focus. And less than 3% when koel is not open.
Other music sites such as spotify or soundcloud don't tend to have
anywhere near this impact, so I doubt it has anything to do with audio
playback


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/phanan/koel/issues/481#issuecomment-260411971, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHrt0i09r7aB2_sXK3BFx2WFHGbcoWpXks5q-KKTgaJpZM4KwcCi
.

<!-- gh-comment-id:260519707 --> @phanan commented on GitHub (Nov 15, 2016): I'm not familiar with this problem tbh – never heard or seen before. What browser/version, and not less important, do you have any funny addons installed? On Tue, Nov 15, 2016 at 2:04 AM, Porco-Rosso notifications@github.com wrote: > It happens from the first song, within I would say 10-20 seconds. > Looking more carefully, CPU usage from the browser hovers around 60% (on > my ~2015 Macbook Pro) while tab is in focus, dropping to less than 10% when > the tab is not in focus. And less than 3% when koel is not open. > Other music sites such as spotify or soundcloud don't tend to have > anywhere near this impact, so I doubt it has anything to do with audio > playback > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > https://github.com/phanan/koel/issues/481#issuecomment-260411971, or mute > the thread > https://github.com/notifications/unsubscribe-auth/AHrt0i09r7aB2_sXK3BFx2WFHGbcoWpXks5q-KKTgaJpZM4KwcCi > .
Author
Owner

@Porco-Rosso commented on GitHub (Nov 15, 2016):

This issue happens for chrome and Vivaldi, Safari is less prone but usage still hovers around 25%

It might be an isolated issue, but I thought I would raise it anyway, incase its a common to others.
Some simple changes might result in better performance. I'll try to see if I can pin it down to something more specific.

<!-- gh-comment-id:260733387 --> @Porco-Rosso commented on GitHub (Nov 15, 2016): This issue happens for chrome and Vivaldi, Safari is less prone but usage still hovers around 25% It might be an isolated issue, but I thought I would raise it anyway, incase its a common to others. Some simple changes might result in better performance. I'll try to see if I can pin it down to something more specific.
Author
Owner

@X-Ryl669 commented on GitHub (Nov 16, 2016):

This is fixed in my fork

@phanan This is due to the song-bar animation. Please check this commit
Basically, CSS animation takes too much CPU (even when very small) because they cause a complete redraw. Using a GIF file instead allows the browser to only replace the part that's modified, and it's invisible to the user, dropping the CPU usage from 30% to ~1,5% for me.
Since the animation is just eye-candy, it's not worth burning CPU for this.

BTW, even if obvious, I allow you to use the gif file from my fork.

<!-- gh-comment-id:260918995 --> @X-Ryl669 commented on GitHub (Nov 16, 2016): This is fixed in my [fork](https://github.com/X-Ryl669/kutr) @phanan This is due to the song-bar animation. Please check this [commit](https://github.com/X-Ryl669/kutr/commit/8b89ae370153369e67f981d515daf640a33f9686) Basically, CSS animation takes too much CPU (even when very small) because they cause a complete redraw. Using a GIF file instead allows the browser to only replace the part that's modified, and it's invisible to the user, dropping the CPU usage from 30% to ~1,5% for me. Since the animation is just eye-candy, it's not worth burning CPU for this. BTW, even if obvious, I allow you to use the gif file from my fork.
Author
Owner

@phanan commented on GitHub (Nov 16, 2016):

@X-Ryl669 See what I have for months in my Koel todo list ;)

image

Do you have a transparent background gif though? That's what I fail to create.
And thanks for the comment/offer of course!

<!-- gh-comment-id:260928766 --> @phanan commented on GitHub (Nov 16, 2016): @X-Ryl669 See what I have for months in my Koel todo list ;) ![image](https://cloud.githubusercontent.com/assets/8056274/20346435/ec04ac24-ac36-11e6-8438-8a7ea7c0fd50.png) Do you have a transparent background gif though? That's what I fail to create. And thanks for the comment/offer of course!
Author
Owner

@Porco-Rosso commented on GitHub (Nov 16, 2016):

bars-transparent
Gave it a shot.

<!-- gh-comment-id:260951076 --> @Porco-Rosso commented on GitHub (Nov 16, 2016): ![bars-transparent](https://cloud.githubusercontent.com/assets/7024527/20349742/026fead0-ac0c-11e6-8ecd-16db2359f127.gif) Gave it a shot.
Author
Owner

@phanan commented on GitHub (Nov 16, 2016):

Thanks, @Porco-Rosso, but the bars don't fade or transform as softly as the CSS version (especially if you notice that last one to the right).

<!-- gh-comment-id:260952656 --> @phanan commented on GitHub (Nov 16, 2016): Thanks, @Porco-Rosso, but the bars don't fade or transform as softly as the CSS version (especially if you notice that last one to the right).
Author
Owner

@phanan commented on GitHub (Nov 16, 2016):

@Porco-Rosso By the way, can you try adding transform: translateZ(0) into .bar like below and see if the CPU goes down?

image

<!-- gh-comment-id:260967051 --> @phanan commented on GitHub (Nov 16, 2016): @Porco-Rosso By the way, can you try adding `transform: translateZ(0)` into `.bar` like below and see if the CPU goes down? ![image](https://cloud.githubusercontent.com/assets/8056274/20351895/11bf2b6a-ac50-11e6-88f2-51cf7351a2ac.png)
Author
Owner

@Porco-Rosso commented on GitHub (Nov 16, 2016):

@phanan
I made the gif very quickly with an online tool. Maybe if I take the time to make one properly, It will look nicer.
Adding transform: translateZ(0) doesn't seem to help.

<!-- gh-comment-id:261051920 --> @Porco-Rosso commented on GitHub (Nov 16, 2016): @phanan I made the gif very quickly with an online tool. Maybe if I take the time to make one properly, It will look nicer. Adding transform: translateZ(0) doesn't seem to help.
Author
Owner

@phanan commented on GitHub (Nov 17, 2016):

Put my poor GIF editing skill to test – better contribution for the animation welcome!

<!-- gh-comment-id:261172978 --> @phanan commented on GitHub (Nov 17, 2016): Put my poor GIF editing skill to test – better contribution for the animation welcome!
Author
Owner

@X-Ryl669 commented on GitHub (Nov 17, 2016):

GIF only allow a single color out of 256 to be transparent. Since the initial animation is using alpha, that can not work well. That's why I've made the animation with the "official" background color instead (and also, without transparency, it takes less CPU since no blending is required by the browser).
The best would have been APNG or WebP, but it's either Gecko either Webkit and I'm not sure for Edge support.

<!-- gh-comment-id:261198368 --> @X-Ryl669 commented on GitHub (Nov 17, 2016): GIF only allow a single color out of 256 to be transparent. Since the initial animation is using alpha, that can not work well. That's why I've made the animation with the "official" background color instead (and also, without transparency, it takes less CPU since no blending is required by the browser). The best would have been APNG or WebP, but it's either Gecko either Webkit and I'm not sure for Edge support.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/koel-koel#341
No description provided.