Vanilla videos Chrome idle CPU performance notes

[marcustyphoon]

tl;dr: enabling vanilla videos causes idle CPU use in Chrome/Edge, but not in Firefox. This appears to not be XKit's fault.

---

This is almost certainly unfixable, or at the very least should be a bug in someone else's tracker (probably Chromium?), but here's some rather strange facts:

• Tumblr causes additional idle CPU usage in Chrome/Edge with Vanilla Videos enabled under certain circumstances. The amount depends on the amount of loaded page content, but with 100 visible posts it's about 10 watts on my laptop, or 75% of the main thread.
• Browser dev tools indicate that this is caused by "style recalculation" (referring to CSS styles), which is fired many times per second in offending circumstances, and is not fired at all when the page is idle in non-offending circumstances.
• Testing with a minimal test case shows that "Recalculate Style" and "Compute Intersections" events are fired repeatedly if an animated element and the Chrome video player with default controls are displayed together, but not if either is by itself. The Firefox video player causes no such events in either case. HTML I was using: https://gist.github.com/marcustyphoon/ca717b70cd2206909e9ecf954a57599d

I observed, and complained about, Tumblr's idle CPU usage in Chrome a while ago, and a fix was recently made to the Tumblr logo making it not a constantly animated element (referenced here, I think) - thanks Staff!

There are, however, still continuous CSS animations on Tumblr, and likely will be in the future even if Staff were to try to optimize away them all. [edit: One of the] culprit[s] right now is a loading icon inside the "check out these blogs" carousel, visible briefly if you scroll all the way to the right. Removing all of these, carefully or with a simple document.querySelectorAll('div[role=progressbar]').forEach(node => node.remove()), immediately caused the CPU usage to go away, in my testing. There may be others ("you're caught up," I would imagine, for one).

In any case, though, the minimal test seems to strongly indicate that this is a Chromium default video player thing, and thus Vanilla Videos cannot avoid it if one is using a Chromium-based browser.

[AprilSylph]

Very interesting!

Testing with a minimal test case shows that "Recalculate Style" and "Compute Intersections" events are fired repeatedly if an animated element and the Chrome video player with default controls are displayed together, but not if either is by itself. The Firefox video player causes no such events in either case.

That definitely makes it a Chromium/Blink bug, holy fuck. I guess we could make Vanilla Video also remove all CSS-animated elements, but I don't want to explain to everyone why it does that for the rest of my life.

The culprit right now is a loading icon inside the "check out these blogs" carousel, visible briefly if you scroll all the way to the right.

Does hiding these carousels with No Recommended also stop them causing this recalculation loop? I'd really like there to be a user solution other than "don't use Chromium".

[marcustyphoon]

Oh, oops - just noticed there's also a progressbar at the bottom of the timeline. Not sure how I didn't consider that earlier!

Also, a note I forgot to mention in the original post: the "pause" button in the Chrome devtools animation tab temporarily drops the CPU load, which I've found very useful investigating these sorts of things.

Does hiding these carousels with No Recommended also stop them causing this recalculation loop?

My forgetting about the animation on the bottom of the timeline aside, it looks from a brief inspect-element that carousels with a display:none from No Recommended indeed don't have animated placeholders at the end of their carousels, which is kinda nice! ...eeexcept that as far as I can tell, this is because instead of loading 15 blog items and a progress bar, they keep loading more and more items until they eventually give up at, in the case of the one I was looking at, 163. So that's not... great, but oh well :D

[marcustyphoon]

One idea to, er, solve? this would be to use the default video player without controls, and either add the controls on click (which causes the CPU load henceforth, and would require adding an indicator of some sort that it's a video and can be clicked on) or implementing non-vanilla controls (which... would make the extension's name inaccurate, as well as, you know, all the other problems with that.)

Hey, I didn't promise a good idea!