mirror of
https://github.com/koel/koel.git
synced 2026-04-25 08:46:00 +03:00
[GH-ISSUE #481] CPU maxed while song playing and tab is in focus #341
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#341
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
All checked? Now also make sure your issue
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.
@phanan commented on GitHub (Nov 14, 2016):
Can you share how long it takes to max the CPU? How many songs, roughly? Thanks.
@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
@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:
@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.
@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.
@phanan commented on GitHub (Nov 16, 2016):
@X-Ryl669 See what I have for months in my Koel todo list ;)
Do you have a transparent background gif though? That's what I fail to create.
And thanks for the comment/offer of course!
@Porco-Rosso commented on GitHub (Nov 16, 2016):
Gave it a shot.
@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).
@phanan commented on GitHub (Nov 16, 2016):
@Porco-Rosso By the way, can you try adding
transform: translateZ(0)into.barlike below and see if the CPU goes down?@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.
@phanan commented on GitHub (Nov 17, 2016):
Put my poor GIF editing skill to test – better contribution for the animation welcome!
@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.