Jarda Snajdr [:jsnajdr] Reporter
	Description • 6 years ago

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)

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 1 • 6 years ago

(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?

	Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo
	Comment 2 • 6 years ago

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

	Jared Wein [:jaws] (please needinfo? me)
	Comment 3 • 6 years ago

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?

	Jared Wein [:jaws] (please needinfo? me)
	Comment 4 • 6 years ago

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

	Jonathan Watt [:jwatt]
	Comment 5 • 6 years ago

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?

	Markus Stange [:mstange]
	Comment 6 • 6 years ago

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.

	Jarda Snajdr [:jsnajdr] Reporter
	Comment 7 • 6 years ago

> 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.

	Doug Thayer [:dthayer] (he/him)
	Comment 8 • 6 years ago

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.

	Mike Conley (:mconley) (:⚙️)
	Comment 9 • 6 years ago

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).