Closed Bug 774508 Opened 12 years ago Closed 12 years ago

[July Campaign] CSS Animations overloading CPU

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: barry, Unassigned)

References

Details

We are exploring animations inside of About:home and wondering what is causing the CPU to spike.  Typically CSS animations should be kicked over to GPU when 3D transforms are introduced in layout, yet we aren't seeing this.

what else could be causing this to consume CPU cycles?

http://people.mozilla.com/~ckoehler/olympics/olympics/snippet/SnippetSandbox.xhtml
Summary: CSS Animations overloading CPU → CSS Animations overloading CPU [July Campaign]
Summary: CSS Animations overloading CPU [July Campaign] → [July Campaign] CSS Animations overloading CPU
Sending this over to GFX for first-level triage/assessment.
Component: General → Graphics
Product: Firefox → Core
Version: 15 Branch → Trunk
We're invalidating lots. That's causing us to spend lots of time painting instead of just compositing like you expect (and would see in Chrome or Safari). DLBI is the silver bullet predicted to fix this.
Depends on: dlbi
Component: Graphics → Layout
My intuition is that having a single animated GIF or APNG for the cauldron flames would be significantly faster. That's my recommendation to you.

It is at least possible for these animations to be layerized and hence GPU-accelerated, but you shouldn't count on it for performance. In particular, a significant portion of our users have no GPU acceleration at all.
Yes, an animated GIF would probably solve the issues, but the whole purpose of this animation is to use HTML5 technologies to dogfood web standards. We would prefer to do HTML5 animations and not HTML4.
(In reply to barry munsterteiger from comment #0)
> causing the CPU to spike.  Typically CSS animations should be kicked over to
> GPU when 3D transforms are introduced in layout, yet we aren't seeing this.

Gecko's decisions about what layers should be associated with buffers on the GPU are a function much more of whether things are changing frequently rather than of the technology used to change them.  (That said, we're working on moving some types of animations to the compositor thread because having them on another thread helps with the smoothness of the animation, but that's largely distinct from the issue here, which is resource consumption.)

It sounds like you're reading performance advice written to help authors tune for Safari.  And the particular things that (common) advice tells authors to do is, frankly, stuff that the browser should be doing for authors rather than stuff that they should need to be taught how to optimize by hand.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
> We're invalidating lots. That's causing us to spend lots of time painting
> instead of just compositing like you expect (and would see in Chrome or
> Safari). DLBI is the silver bullet predicted to fix this.

That also suggests that the over-invalidation is likely easy to work around by changing the structure of the page.  (DLBI obviously isn't going to fix this by the time of the Olympics; we'll be lucky to have it on nightly by then.)

(In reply to Chris More [:cmore] from comment #4)
> Yes, an animated GIF would probably solve the issues, but the whole purpose
> of this animation is to use HTML5 technologies to dogfood web standards. We
> would prefer to do HTML5 animations and not HTML4.

Animated images are a perfectly reasonable technology to use for animated images.  What's new with CSS animations is that they can animate content containing lots of other Web technologies, but that doesn't seem necessary here.
Using paint_flashing it does not seem to me that over-invalidation is the problem. Loading snippet.html directly (so there are no complex background) and commenting out everything but the flames will still uses about 85% cpu, enabling only the shadow uses about 50% cpu (on my slow machine with no supported gpu). Seems to me that css-animations are being inefficient and trying to run with to high a framerate (at least for long running animations). It ought to be possible to scale 7 images in a 141x138 at a good frame rate even on a slow machine.

Note that dropping the "-moz-perspective" declaration from shadow-perspective-wrapper drops cpu usage for that element from 50% to 5% in this machine. But rewriting the flame to animate using background-size (and not use transform) did not seem to help much.
Barry, I completely forgot: using 3D animations for Firefox will actually make your perf *worse* in a lot of cases. We emulate 3D using software on platforms that don't support hardware acceleration (i.e., a lot of our Windows XP users).

My first recommendation remains to use an animated GIF or APNG. But, at a minimum, you'll want to remove the -moz-perspective and other 3D transformations.
Joe + David: Though it sounds like a horrible pain in the ass rendering-wise, you guys may want to take a hard look at this implementation decision in relation to what developers do today on other platforms, and what is increasingly becoming the established practice in mobile web development.  For us on the web development side (Particle), translate3d() is synonymous with "please render this on the GPU" and so much so that it's become a kind of shorthand for that instruction.  We very often will put transform: translate3d(0,0,0) on elements just to make sure they are getting out of the CPU's rendering to-do list.  Chrome (for example) also provides a tool which draws boxes around the hardware accelerated elements so we can reality check this behavior and WebKit docs in several contexts recommend or imply it.

I agree that we *shouldn't* have to do this as developers, but it's also not realistic at this point to expect a -moz-render: GPU; kind of option any time soon.  In practice, translate3d is just what happens out there, and I think it's probably important for Gecko to begin to "work the same way" when given the same instructions in CSS.  This becomes all the more important when you look at the wave of utilities like  Prefixfree (http://leaverou.github.com/prefixfree/) and what we do in Neutrino to let developers write CSS without prefixes and keep their sanity.  Given the state of Mobile Safari and Chrome Mobile, I don't think we'll ever see much in the way of CSS-based animation for mobile which doesn't specify translate3d.  It will be a hard case to make to mobile web developers in particular that they should maintain multiple CSS files to support B2G, most of them are currently fleeing the Android ecosystem for exactly that kind of frustration!
Update: These snippets launched on all Firefox channels this morning and we have got very positive press thus far. We have also got positive feedback from developers that they were very happy that this wasn't an animated GIF and they quickly took it apart to see how it was constructed. We released the updated snippet with the 3D transformations removed to reduce the load on the CPU. We will be doing more animation in the future and it would be unfortunate that the CPU becomes the limiting factor quickly with what we can do.
(In reply to David Baron [:dbaron] from comment #5)
> (In reply to barry munsterteiger from comment #0)
> > causing the CPU to spike.  Typically CSS animations should be kicked over to
> > GPU when 3D transforms are introduced in layout, yet we aren't seeing this.
> 
> Gecko's decisions about what layers should be associated with buffers on the
> GPU are a function much more of whether things are changing frequently
> rather than of the technology used to change them.  (That said, we're
> working on moving some types of animations to the compositor thread because
> having them on another thread helps with the smoothness of the animation,
> but that's largely distinct from the issue here, which is resource
> consumption.)

True, off-main-thread CSS animations still use CPU.

> It sounds like you're reading performance advice written to help authors
> tune for Safari.  And the particular things that (common) advice tells
> authors to do is, frankly, stuff that the browser should be doing for
> authors rather than stuff that they should need to be taught how to optimize
> by hand.

I don't see this as a clear-cut case of browsers-know-best. It's a hard optimization problem. Giving developers guaranteed-to-relieve-the-CPU tools can win too. A conspicuous, big, messy example is of course WebGL. But translate3d is a nice, small example. If Apple created a de-facto standard not just for the syntax and semantics, but also performance and specifically GPU-not-CPU execution, we should go with the flow.

/be
> My first recommendation remains to use an animated GIF or APNG. But, at a minimum, > you'll want to remove the -moz-perspective and other 3D transformations.

I don't think I agree with this recommendation in the general case. A very large number of users these days have GPU acceleration with Firefox (hundreds of millions). In these cases 3D transform is faster and uses less CPU/battery etc.

Also, OMT CSS animations all execute on the GPU. We support 3D transform and opacity change, which all are GPU-based.
(In reply to Andreas Gal :gal from comment #13)
> Also, OMT CSS animations all execute on the GPU. We support 3D transform and
> opacity change, which all are GPU-based.

Excellent! This prompts the question: where are dz's OMT CSS patches, meaning tryserver or nightly builds? Could Aubrey (misteranderson@gmail.com) or anyone easily test a non-B2G build that includes them?

/be
Re comment 12:  My point in the beginning of comment 5 was that we should be using the GPU in *more* cases than described in comment 0:  for transforms combined with any type of dynamic changes, not just for transforms combined with animations.  I didn't say that we weren't using the GPU for this case; I suspect we are, and I don't see any reason to think Jeff was wrong in identifying the underlying problem in comment 2.  Given that DLBI should be landing soon, I think it's a waste of time to debug invalidation performance issues in pre-DLBI builds.
dbaron: agree on ruling out over-invalidation first, but comment 6 suggests it is not the (or a big enough) problem in this particular bug. Maybe Jeff M. can reply definitively.

/be
(In reply to Brendan Eich [:brendan] from comment #16)
> dbaron: agree on ruling out over-invalidation first, but comment 6 suggests
> it is not the (or a big enough) problem in this particular bug. Maybe Jeff
> M. can reply definitively.
> 
> /be

On the URL given in comment 1 we are definitely over-invalidating. A DLBI build has better invalidation behaviour but it is also rendering it incorrectly so it's difficult to judge whether it's just getting lucky. If there's a simpler test case that doesn't over invalidate I'd be happy to take a look. I also expect we may have performance problems on non-hardware accelerated windows while compositing layers.

The snippet isn't supported by Chrome or Safari so it's difficult to judge whether they are doing a better job or not.
If you really want to test Safari vs Chrome vs Firefox, you can test with this page as it is has a static copy of what was deployed via the snippet.

http://people.mozilla.com/~ckoehler/olympics/olympics/snippet/SnippetSandbox.xhtml

Ignore the two text snippets below the search box as those are just tests.
(In reply to Andreas Gal :gal from comment #13)
> > My first recommendation remains to use an animated GIF or APNG. But, at a minimum, > you'll want to remove the -moz-perspective and other 3D transformations.
> 
> I don't think I agree with this recommendation in the general case. A very
> large number of users these days have GPU acceleration with Firefox
> (hundreds of millions). In these cases 3D transform is faster and uses less
> CPU/battery etc.

There is no way to detect whether a browser has GPU acceleration, and using 3D transforms absent GPU acceleration will result in worse performance.

However, we detect whether things are using 3D by the state of the matrix, so if it's a no-op "3D transform", it will result in no change whatsoever in performance.

> Also, OMT CSS animations all execute on the GPU. We support 3D transform and
> opacity change, which all are GPU-based.

This is true now, but will not be true once we start supporting software-composited OMTC.
This seems to be what I experience on this site: http://www.tomshardware.com/

According to Process Explorer, Fx consumes CPU & GPU while I'm on top -only- of the page. If I move at the bottom, for instance, it goes idle. If I disable HWA the CPU utilization is being increased.
Examples to mention:

Tomshardware: 8-10% CPU & 15-20% GPU Utilization, both on low-state clocks. 

Homepage: 5-7% CPU & 12-15% GPU Utilization.
The problem with tomshardware.com seems to be caused by a small animated gif used as a background image for the "Latest News" (in the main content area) and the "Forum Live Feed" (in the right column) blocks. Even though the image is 16x16 and set to no-repeat, it causes the entire box to be repainted continuously. To check:
- Go to http://www.tomshardware.com/ and observe excessive cpu-usage when the "Latest News" and "Forum Live Feed" is in view.
- Use Firebug or the build-in style editor to search for "ajaxLoader" and disable the property "background-image:url(http://m.bestofmedia.com/sfp/images/design/ajax/loading.gif);" and observe the cpu-usage drop.

I minimized the page to this, but it only show the high cpu-usage when paint_flashing is enabled:
<!DOCTYPE html><html><body>
 <div style='
   background-image:url(http://m.bestofmedia.com/sfp/images/design/ajax/loading.gif);
   background-repeat:no-repeat;
   height:500px;'></div>
</body></html>
see reference to the bug that I filled not a long time ago: bug 769924.
> There is no way to detect whether a browser has GPU acceleration, and using
> 3D transforms absent GPU acceleration will result in worse performance.

Do you think that its accurate that all hardware produced today (or the last few years) has a GPU? Do you think that we have reached the point where we can optimize for hardware with a GPU?


> This is true now, but will not be true once we start supporting
> software-composited OMTC.

What hardware is software-composited OMTC targeting?
(In reply to Andreas Gal :gal from comment #24)
> > There is no way to detect whether a browser has GPU acceleration, and using
> > 3D transforms absent GPU acceleration will result in worse performance.
> 
> Do you think that its accurate that all hardware produced today (or the last
> few years) has a GPU? Do you think that we have reached the point where we
> can optimize for hardware with a GPU?

Yes and no.

Yes, because even the integrated GPU in Nehalem (released 2008) would probably be a benefit if we used it.

No, because we require drivers >= June 2010, and there are many computers on which the users are prohibited from installing new drivers, let alone wanting to do so.

> > This is true now, but will not be true once we start supporting
> > software-composited OMTC.
> 
> What hardware is software-composited OMTC targeting?

The plurality of our usersbase: that is, computers running Windows XP with blocked drivers.
This survey seems relevant even though it is based on crashes rather than usage:
http://people.mozilla.org/~bjacob/gfx_features_stats/
(via https://blog.mozilla.org/bjacob/2012/08/02/extracting-useful-data-from-crash-reports/ )

It shows that currently just below 40% get accelerated layers compared to 20% a year ago.
Windows XP, on the other hand, has < 10% layers acceleration.
My two cents: don't drive by the rear-view mirror.

Our users will be moving off of XP over the next few years, and we are working on mobile initiatives where competitive table-stakes mean GPU optimization, and where without success and greater share for Mozilla mobile UAs in the next few years, declining (relative to the sum of mobile + desktop) desktop share is not going to be enough anyway.

Comment 19:
> There is no way to detect whether a browser has GPU acceleration, and using
> 3D transforms absent GPU acceleration will result in worse performance.

This seems to suggest that web authors generally write the same content-set or web-app for desktop, including our old-driver-plagued XP trailing edge, and for modern GPU-accelerated targets, let's say "mobile". As far as I can see that's not the case. The FF start page Olympic torch flames animation is perhaps an exception that could OS sniff and do something different on XP, if needed.

The bottom line: mobile content is authored with iOS-first or at least GPU-acceleration in mind and expected, if not demanded (Android catching up to satisfy that demand and compete head to head with Apple). Modern desktop OSes are right behind and trying to converge, to the extent that "desktop" merges with portable form factors (laptops/netbooks/tablets). Therefore we ought to GPU-optimize first and broadly, and match iOS Safari where it matters most to developers.

Mitch Kapor once said something at an early Mozilla board meeting that stuck with me and which seems relevant here: "don't invest in the trailing edge".

/be
There's not really anything for us to do here.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Resolution: INCOMPLETE → FIXED
Resolution: FIXED → INCOMPLETE
Could someone please cite the bugs for OMTC CSS animations, transitions, etc. on desktop platforms? I trust these bugs are on file.

/be
Bug 706179. Desktop platforms will be a natural fallout of implementing OMTC on desktop, which is bug 756608, bug 756606, bug 756601, bug 722012, and bug 703484.

Note that OMTC will have no effect on CPU utilization (in fact it'll probably make it epsilon worse, due to thread marshalling etc), which is what this bug is about.
Is anyone willing to do a QA test of CPU of the snippet below on Firefox/Chrome/Safari on desktop to see if with this specific animation if any of the browsers are better or worse? The test would have to control other factors so you can get apples-to-apples comparisons.

http://people.mozilla.com/~ckoehler/olympics/olympics/snippet/SnippetSandbox.xhtml
You need to log in before you can comment on or make changes to this bug.