It seems not easy to address the partial pre-rendering of content with an animated transform. Instead, it seems simpler just relax, the size check in nsDisplayTransform::ShouldPrerenderTransformedContent() when the painting is for WebRender because of the following.

• When webrender is enabled, gecko already allocates whole svg image at nsDisplayImage::CreateWebRenderCommands() and the image does not needs additional TextureClient allocation for async animation.
• When webrender is enabled, content process normally does not allocate TextureClient except canvas and video.
• When disiplay list does not support Webrender, part of the display list is rendered as blob image. and does not allocate TextureClient in content process.

With attachment 9035842 [details] [diff] [review], fps was improved from 3fps to 40fps.

Got profile with attachment 9035842 [details] [diff] [review]. Cpu usage in content process was decreased.

https://perfht.ml/2H5MB8l

try result with attachment 9035842 [details] [diff] [review].

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d7148cd3cc8d7c0ebcbf36f8ad89257ff967aff

https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=74314384ea5b37e654b1af0721875f6e9bbf83df&newProject=try&newRevision=3d7148cd3cc8d7c0ebcbf36f8ad89257ff967aff&framework=1

attachment 9035842 [details] [diff] [review] had a problem. absoluteLimit was not big enough to trigger async animation on my laptop(P50 Win10).

attachment 9036507 [details] [diff] [review] relaxed more. With it, async animation happened more on my laptop(P50 Win10) and fps was around 46fps.

attachment 9036507 [details] [diff] [review] caused dom/animation/test/mozilla/test_restyles.html test failure.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=737188207907659380073bcbe087022f9291451c

:hiro, do you know why attachment 9036507 [details] [diff] [review] could cause test_restyles.html test failure?

It's hard to tell without the information which test actually fails. My best guess is that the last one [1].
Now the transform animation on a big element in the test runs on the compositor due to the relaxed restrictions?

[1] https://hg.mozilla.org/mozilla-central/file/e49161da5784/dom/animation/test/mozilla/file_restyles.html#l1857

Ah, the test faild at "ok(!SpecialPowers.wrap(animation).isRunningOnCompositor)" in flush_layout_for_transform_animations(), because attachment 9036507 [details] [diff] [review] permits async animation of large frames.

attachment 9036804 [details] [diff] [review] addressed test failure.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dcac6cb19b86b055d93515e483301a7101c11a20

https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=1e313994b4782935b9a94a5075f8e8dbe4753c55&newProject=try&newRevision=dcac6cb19b86b055d93515e483301a7101c11a20&framework=1

Comment on attachment 9036804 [details] [diff] [review]
patch - Relax aysnc animation restriction with WebRender

:hiro, can you feedback to the patch?

Comment on attachment 9036804 [details] [diff] [review]
patch - Relax aysnc animation restriction with WebRender

I am afraid that I am not familiar with WebRender to understand the reasoning in comment 10. Could you please get feedbacks from WebRender guys?

One thing from animation perspective I am still wondering why some test cases in dom/animation/test/chrome/test_animation_performance_warning.html still pass with this patch. There are also test cases of transform animations on large elements.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #25)

One thing from animation perspective I am still wondering why some test cases in dom/animation/test/chrome/test_animation_performance_warning.html still pass with this patch. There are also test cases of transform animations on large elements.

I confirmed that mochitest chrome did not run with WebRender. Just enabling it caused several test failures including dom/canvas/test/chrome/test_drawWindow_widget_layers.html like the following.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=66f310b8ae03324f64d1927613eb032b3c6608e9&selectedJob=222379155

Actually the following mochitests are not enabled on linux-qr-tests yet.

• mochitest-browser-chrome
• mochitest-chrome
• mochitest-clipboard
• mochitest-devtools-chrome

Created Bug 1520705 for enabling mochitest-chrome on WebRender.

https://hg.mozilla.org/mozilla-central/rev/d1b533985274

For records, this change was backed out in bug 1587713, but the site in question should work fine since bug 1656418. It's much smoother with enabling layout.animation.prerender.partial at least on my Window 10 laptop on a local debug build.

The performance seems a lot better now. I still see graphical glitches and content that appears to be rendered at a resolution that is too low, but those should probably be treated as separate bugs.