Open Bug 1578161 Opened 5 years ago Updated 2 years ago

[meta] Performance issues with https://www.tvnow.de

Categories

(Core :: Performance, defect, P3)

Product:
Core
Component:
Performance
Type:
defect

Tracking

()

People

(Reporter: whimboo, Unassigned)

References

(Depends on 3 open bugs)

Details

(Keywords: meta, perf)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190901214807

Steps:

  1. Open https://www.tvnow.de/serien/24-stunden-wildnis-17402/2019-08/episode-3-jaeger-des-dschungels-1681769
  2. Observe the CPU load

After loading the page it will consume about 30% of the CPU even when you aren't doing anything. As it looks like this is due to the breathing animation, which is visible when hovering over the play button. But even when not doing so, the CPU is used quiet a lot.

Emilio, could you maybe have a look? Thanks.

Flags: needinfo?(emilio)

Unfortunately I'm not in Berlin r/n, so it'd have to wait until the twenty-something of this month when I'm back, because the video is not available here in Spain.

Any chance you could save the page and see if the problem keeps reproducing, and if so attach it to the bug?

Flags: needinfo?(emilio) → needinfo?(hskupin)
Component: CSS Parsing and Computation → CSS Transitions and Animations

It doesn't seem to be the "breathing" animation of the play button, but some hidden, infinite "buffering" animation. It seems to be in a visibility: hidden subtree.

I'm building atm so my fans are spinning regardless, but I can try to take a profile when my build finishes.

Anyhow, Henrik, any chance you could try to take a performance profile of the page sitting idle on your machine?

Sorry, but after upgrading to the latest nightly I'm not able to publish the profile. It seems to be stuck. But yes, I can also see the higher CPU load when loading your before mentioned URL.

Flags: needinfo?(hskupin)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #4)

Sorry, but after upgrading to the latest nightly I'm not able to publish the profile. It seems to be stuck. But yes, I can also see the higher CPU load when loading your before mentioned URL.

That's a shame, can you make sure there's a bug on file for that?

Local profile: https://perfht.ml/2kd6ksl

It doesn't seem like there's a lot going on on my machine. Hiro, is there an easy way to see whether the animations are being throttled other than with a custom build?

It'd be good if the animation inspector could highlight that...

Flags: needinfo?(hikezoe.birchill)

On WebRender I've been using these prefs.
gfx.webrender.debug.new-frame-indicator
gfx.webrender.debug.new-scene-indicator

On non WebRender I've been using this pref
layers.acceleration.draw-fps

With either way you can see some indicators at the top left of the browser window.
That's said, it will not help in most cases, I often have to debug into detail why the animation in question is not optimized properly.
I will check the site tomorrow anyway.

Strange, so with the upgrade to the latest Nightly build I cannot see this high CPU usage anymore. Whether for the URL I have given in comment 0, nor for yours. And this is for both core animation enabled or not.

Here a profile with Firefox 69 RC: https://perfht.ml/32mYw7G

Not sure how helpful this is given that this is still not 70. My problem with the profiler in 70 is that it doesn't finish with compression after I unchecked options. As such it never uploads. I will see how to find a pattern, and will file a bug for that.

It'd be useful to try to find a regression range (well, fix range, really) if you think it's fixed on Nightly.

You can do that with mozregression --find-fix --bad 69 or such.

I think I am still seeing animations consuming the main-thread. There are two different kind of animations. One is a background-color animation covered by other elements (We have bug 1471377 for that). The other is three transform/opactiy animations in visibility:hidden subtree.

As for the background-color animation, it seems to run on the compositor thread with non-WebRender (I assume devtools is correct). For the other animations I have no idea why our optimization doesn't work, need to debug it.

Flags: needinfo?(hikezoe.birchill)

Is there anything you would still need from me? Or are all the details clear enough.

Flags: needinfo?(hikezoe.birchill)

No, I think I could reproduce this issue locally. We just need to investigate why the animation in question is not optimized as expected.

Flags: needinfo?(hikezoe.birchill)

The priority flag is not set for this bug.
:kamidphish, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dglastonbury)
Flags: needinfo?(dglastonbury)
Priority: -- → P3

Hey Hiro, any idea when you might a bit of time to check that? It bites me each and every day. Maybe something has changed here, and a new profile shows quite a bit of activity in a JS script: https://perfht.ml/2Rou36D.

Now the background color animations are properly optimized (they are out of viewport), I can't see any other animations that are not optimized. So, I believe the JS script (it seems it's driven by setTimeout calls) causes restyling repeatedly. I wonder whether there are something we can optimize..

Component: CSS Transitions and Animations → Layout
Summary: High CPU load on https://www.tvnow.de due to breathing CSS animation → High CPU load on https://www.tvnow.de

Note, that the high CPU load is always happening, also when the tab is in the background - in my case it's a pinned tab. Also I noticed that the recently attached profile all URLs have been stripped out. When I see it again, I will record a new profile.

Flags: needinfo?(hskupin)

I had to look around for a bit, but here is a new profile which shows more than 200% CPU usage overall for Firefox when watching non-premium content of https://www.tvnow.de/serien/unter-uns-20/2020-02.

Here is the appropriate profile: https://perfht.ml/2Ux2iKN

Emilio, might you have time to have at least a quick look at it?

Flags: needinfo?(hskupin) → needinfo?(emilio)

Here's two profiles I took: https://perfht.ml/388vqwb / second profile with long url.

The first one is without playing the video, and the page doesn't look like it has much CPU usage. In the second the main thread is busy-ish just doing some main-thread animation (the progress bar contains various elements that animate using transform on the main thread, looks like). But it doesn't look outrageous.

Other than that, I can repro high CPU usage when playing that content. But I can repro the same in other browsers (read: Chrome) too... Can you?

I tried to take all the threads in the profiler and I don't see video decoding and such showing up... which is a bit surprising.

But I suspect that if you're not seeing the high CPU usage in other browsers it may be because they're managing to do hardware video decoding, instead of software... or something of that sort? Basically the main thread looks somewhat busy, but for me Firefox consumes less CPU than Chrome while playing that video. But you're on mac so everything can be different :)

Maybe some of the media folks can chime in? Jean-Yves, do you know if there's something fishy going on from the media point of view?

Also, Henrik, is this better with WebRender by any chance? Your compositor looks somewhat more busy than mine, somehow (but again, different OSes, so YMMV).

Flags: needinfo?(emilio) → needinfo?(jyavenard)

I don't think that this is media or gfx (webrender) related. Ove the weekend when I detected that the tab was using 70% CPU again even with the Firefox instance been minimized, I checked the No Script settings. I thought that maybe a blocked script could cause that. And indeed, when temporarily allowing all hosts run execute JS the CPU load dropped to normal. When I reverted the temporary setting, it stayed that way.

Here another interesting profile which seems to be different from all the ones above: https://perfht.ml/2SlAcRk. We spend about 90% of the time in mozilla::dom::TimeoutManager::ClearTimeoutInternal. I assume this is worth a different bug in DOM? Olli what do you think?

Flags: needinfo?(bugs)

Sure, unless the page is calling clearTimeout in a loop, or if it has insane amount of timers. That latter wouldn't actually be anything new - some pages have added more and more timers.
Do you think you could create profile using Nightly. That would give better symbols, possibly.

We could certainly improve clearTimeout performance. Right now it is going through a list. It should just be a hashtable lookup.

Anyhow, better to file a separate bug for seemingly different perf issue.

Flags: needinfo?(bugs)

As we have seen since the bug has been filed a couple of different issues have been found regarding performance on this page. So I think the best right now is to make this a meta bug. I hope moving it into Core:Performance is fine too?

For each and every individual bug I'm going to file dependencies.

Component: Layout → Performance
Keywords: meta, perf
Summary: High CPU load on https://www.tvnow.de → [meta] Performance issues with https://www.tvnow.de
Depends on: 1615564

redirecting

Flags: needinfo?(jyavenard) → needinfo?(padenot)
Depends on: 1639667

Note that with the upcoming changes from bug 1615564 there will be a massive improvement when using this website. I will still keep an eye on it for a while to ensure we have a better performance now.

Flags: needinfo?(padenot)
Depends on: 1641673
Depends on: 1652516
Depends on: 1676210
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.