David Baron :dbaron: Reporter
	Description • 11 years ago

https://twitter.com/thebabydino/status/432638457052008448 reports an example of animated 3-D transforms being slow.

Please leave this bug about **this testcase**; I'd like to effectively make this a metabug for the problems in this testcase; other example should go in other bugs, particularly if they hit different sets of problems.


On Linux, I'm seeing about 3.5fps; (somewhat-out-of-date) Chromium goes much faster.

I'll attach the testcase and some jprof profile data (with commentary).

	David Baron :dbaron: Reporter
	Comment 2 • 11 years ago

On Linux, with Basic layers, the breakdown is basically (in a jprof profile, realtime, interval 0.01s, 8065 samples):

 * 83.1% painting (i.e., in PresShell::Paint(nsView*, nsRegion const&, unsigned int))

 * 10.8% overflow computation (i.e., not above, and in mozilla::OverflowChangedTracker::Flush())

 * 5.8% restyling (i.e., not above, and in mozilla::RestyleManager::ProcessPendingRestyles())

 * 0.2% other

(totals add to 99.9% due to rounding)


I haven't looked closely, but I'm hoping that bug 931668 will help with the 5.8% restyling.

I *think* the overflow computation algorithm that handles 3-D stuff is inefficient in that it makes multiple (unnecessary) passes over the same content, though I'm not sure that it's doing this.  We should spin off a separate bug for this.

Inside the painting, 43.3% (of the total, not of the painting) is __poll called by xcb_connect_to_fd called by ... ... by _XReply called by XGetImage ... ... called by _cairo_xlib_surface_acquire_source_image ... ... called by mozilla::gfx::SourceSurfaceCairo::GetDataSurface()

Also inside the painting, 11.6% (of the total) is _moz_pixman_image_composite32.


I'll try another profile with OpenGL layers, which is what I meant to do in the first place.

	David Baron :dbaron: Reporter
	Comment 3 • 11 years ago

With GL layers, I'm seeing (not surprisingly) a lower portion of the time painting.  With the same settings, and with 6356 samples, I got:

 * PresShell::Paint is 42.2% of total
 * mozilla::OverflowChangedTracker::Flush() is 34.3% of total
 * mozilla::RestyleManager::ProcessPendingRestyles() is 22.3% of total
 * remainder is 1.1%

(each line excludes anything counted towards the previous lines, but is still a percentage of the overall total)

	David Baron :dbaron: Reporter
	Comment 4 • 11 years ago

I put a jprof profile of the painting slice, with GL Layers on Linux (.html.gz) in attachment 8374522 [details] (accidentally attached to the wrong bug, but no need to upload twice).  (It's easy to profile the testcase yourself in a different tool if you prefer that, though.)

I'm curious who would know what we should be doing (either ongoing work or new work that we ought to do) to improve the performance of the painting segment of this profile (which is the largest chunk, although not quite a majority).  Pinging BenWa as an initial guess, though feel free to pass the request along.

(No urgency, but seems like something we should be improving.)

	David Baron :dbaron: Reporter
	Comment 5 • 11 years ago

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #4)
> I put a jprof profile of the painting slice, with GL Layers on Linux
> (.html.gz) in attachment 8374522 [details] (accidentally attached to the
> wrong bug, but no need to upload twice).

Actually, the upload was incomplete (I tried to cancel it), so I'm attaching it here.

	Benoit Girard (:BenWa)
	Comment 6 • 11 years ago

Getting about 10 FPS on my end. Trim the end of the profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=4a18d784a70be244acf7b1de2c59cf0684cef925

Style flush takes ~50% of the runtime so it's a bottleneck. Matt can we do better with the 'RecomputePreserve3DChildrenOverflow(nsIFrame*, nsRect const*)' here?

A large chunk of the remaining time is with in DisplayList/DisplayItem code.

	David Baron :dbaron: Reporter
	Comment 7 • 11 years ago

(In reply to Benoit Girard (:BenWa) from comment #6)
> Getting about 10 FPS on my end. Trim the end of the profile:
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=4a18d784a70be244acf7b1de2c59cf0684cef925
> 
> Style flush takes ~50% of the runtime so it's a bottleneck. Matt can we do
> better with the 'RecomputePreserve3DChildrenOverflow(nsIFrame*, nsRect
> const*)' here?

Let's discuss that in bug 971349.

(And I'd like to see the other style perf improvements in bug 931668 before worring about the other style part here.)

	Mayank Bansal
	Comment 8 • 6 years ago

This performs much better with WR : https://perfht.ml/2O29lUT (and much better than chrome)
should block bug 1464426