View Issue Details

IDProjectCategoryView StatusLast Update
0014853MMW 5Now Playingpublic2020-07-14 12:18
ReporterLudek Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0014853: Very high CPU utilization during playback in Now Playing > 'Large Lyrics' layout
DescriptionWhen I play a track with lyrics and the view is Now Playing > 'Large Lyrics' layout then CPU utilization is very high (30% -- which are two cores on my i7)
TagsNo tags attached.
Fixed in build2128

Relationships

related to 0015161 closedjiri Now Playing: 'full list' has very high CPU utilization 

Activities

Ludek

2018-05-31 20:53

developer   ~0050465

Last edited: 2018-05-31 21:02

Debugging a little and I found that the CSS class 'veryLargeShadowedText' is causing this with combination of the background image animation (background image scrolling during playback).

It took me a while to find this, because the issue appears even for artists without the background image (and unfortunately I tested on such an artist at first)

jiri

2018-06-01 12:10

administrator   ~0050470

Yes, I've seen this in the past, but haven't decided what to do about it -- the current implementation looks quite good and it's just a bit too CPU intensive. Leaving this open to decide later whether some kind of a change is needed.

Ludek

2018-06-01 13:44

developer   ~0050471

Last edited: 2018-06-01 13:47

Isn't the solution just disabling the background image animation scrolling for this layout ?

It looks like quite severe issue to me, because it can drain the user's battery while playing tracks.

jiri

2018-10-17 09:08

administrator   ~0051357

It's actually supposed to be disabled, it's the default for this view (and I've just hardcoded it, to be sure).

However, there's a problem, after deleting persistent.json (for a fresh start) and switching to 'Lyrics' NP view, BackgroundImage.restoreState() is called and backgroundType is set there to 'albumdark'. There shouldn't be any value in restoreState provided, since we started with a fresh persistent.json.

petr

2018-10-17 13:16

developer   ~0051360

Fixed

peke

2018-10-19 02:13

developer   ~0051384

Verified 2129

peke

2020-07-14 12:18

developer   ~0058953

re tested 2260

CPU utilization is normal now.