STR: 1. Open a tab with URL that returns 401 and shows an auth dialog 2. This causes the tab throbber animation to run for a long time 3. Watch the CPU usage of Firefox and other OS processes related to graphics Actual result on macOS: WindowServer process uses 20% CPU Firefox Nightly process uses 12% CPU kernel_task process uses 11% CPU Expected result: I'd expect a simple and small animation like this to not have any noticeable impact. The tab throbber performance got a lot of attention in bug 1352119. Can the animation be optimized even more, or is this the best we can currently extract from the web platform? Used software: macOS 10.13.3 on 2013 Retina MacBook Pro with NVIDIA graphics latest Firefox Nightly (2018-02-19)

(In reply to Jarda Snajdr [:jsnajdr] from comment #0) > Can the animation be optimized even more, or is this the best we can > currently extract from the web platform?

Can you generate and attach performance profile. See https://perf-html.io/ for directions.

The SVG is located at https://searchfox.org/mozilla-central/source/browser/themes/shared/tabbrowser/loading.svg :jwatt, do you see anything in the SVG that we could change to optimize this?

This webpage describes the technique that we use here, http://msuja.ws/svg.html

I put up the following page to test the loading throbber: https://jwatt.org/tmp/load-never-finishes.php Profile: https://perfht.ml/2FHab9q Markus, any thoughts?

The CPU usage here comes entirely from platform graphics side of Gecko. No amount of optimizing the SVG will help here. Before the graphics problem is addressed, the only change that would help from the front-end side would be to reduce the frame rate of the animation. The profile shows that the main threads are almost entirely idle, but the compositor thread is only 89% idle. Here's an inverted view of the compositor thread: https://perfht.ml/2FAD2sI mach_msg_trap and _psynch_cwait are both functions that only wait, and they take up 70% + 19% of the time. Here's a non-inverted view with samples in those two functions excluded: https://perfht.ml/2FAbbZX The call tree in the profile makes it look like a death by a thousand cuts. 5% AsyncCompositionManager, 17% memory allocation / deallocation, 33% DrawQuad drawing tiles, 10% drawing color layers, 8% DrawWindowOverlay, 8% invalidation. The main problem is that we composite the content even if only the tab bar changes. Traversing the layer tree for the entire window for invalidation, animation sampling and culling has some overhead, but the worst part is submitting the draw commands to the GPU. With WebRender we're currently discussing "document splitting" such that the CPU work for the chrome would be independent from the CPU work for the content. The next step would be to use different CoreAnimation layers for chrome and content, which would save the cost to composite the content. And the final step would be to create a separate CoreAnimation layer for the throbber's transform layer so that all the cost of recompositing the throbber would be moved into the Window Server. The Window Server's high CPU usage is probably caused by the fact that our window is not detected as being opaque, so the Window Server composites other windows underneath the Firefox window every time Firefox wants to recomposite. Timothy Nikkel is currently looking into fixing this.

> Can you generate and attach performance profile. Markus reproduced everything that was happening on my box, too. I have nothing to add at this moment.

It seems like for fxperf this is a bit of a heavy lift, and as it might get tackled by the WebRender folks it seems like a good idea to revisit it later.

I think mstange covered everything in comment 6. There is a similar bug open in bug 1428704 where it seems that high-framerate animations on the compositor might be affecting page load time (by stealing CPU cycles to update the clock).