Bugzilla

The animation in the sidebar is a CSS transform transition. It is janky because it seems to be running on the main thread, and there is JavaScript code that runs for long times during the animation.
Chrome is able to run the animation on the compositor.

I don't see big differences in the profiles between WebRender and non-WebRender.
Here's one excerpt each: non-WR: https://share.firefox.dev/2Xjs59v WR: https://share.firefox.dev/3nllJkG
Looking at the screenshots, the non-WR animation seems a bit smoother in this example because non-WR seems to be able to get a few more main thread frames into the gap between the first jank and the second jank. The first jank is the click event listener, and the second jank is a promise microtask that seems to run after a progress or suspend DOM event.

As for the display list building times, yes, they are bad, but WR seems to be doing slightly better than WR. The RefreshDriverTick markers on WR are slightly shorter overall.

The animation in the sidebar is a CSS transform transition. It is janky because it seems to be running on the main thread, and there is JavaScript code that runs for long times during the animation.
Chrome is able to run the animation on the compositor.

I don't see big differences in the profiles between WebRender and non-WebRender.
Here's one excerpt each: non-WR: https://share.firefox.dev/2Xjs59v WR: https://share.firefox.dev/3nllJkG
Looking at the screenshots, the non-WR animation seems a bit smoother in this example because non-WR seems to be able to get a few more main thread frames into the gap between the first jank and the second jank. The first jank is the click event listener, and the second jank is a promise microtask that seems to run after a progress or suspend DOM event.

As for the display list building times, yes, they are bad, but WR seems to be doing slightly better than non-WR. The RefreshDriverTick markers on WR are slightly shorter overall.