When navigating through images on the sidebar as in https://imgur.com/gallery/a4Jm9nR Firefox animates things much jankier (and displays far less frames) than Chrome.

Firefox profile: https://share.firefox.dev/2XitAVr

Chrome profile: https://share.firefox.dev/35exC5R

Some information gets lost when importing the Chrome profile into profiler.firefox, most of the native code run during the frames in Chrome is indeed layout/layers as well. Uploading the original Chrome profile for completeness [1].

[1] https://faraday.basschouten.com/mozilla/Profile-20210106T164319.json

Tested this without WebRender and it's much, much better there.

https://share.firefox.dev/3s16OPZ

Overall experience is still significantly less responsive than in Chrome. But that may not be graphics related.

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.

To trigger the animation manually, do the following:

• In the DOM inspector, find the <div> that's the child of the .Gallery-Sidebar-posts div (and the parent of the .Gallery-Sidebar-PostContainer divs).
• Set class="scroll" on it. This enables a transition rule.
• Use inline styles to set various transforms on it. In the animation inspector, notice that these transform transitions are not accelerated.

Hiro, do you know why this animation does not take advantage of partial prerendering?

That's because the target transition element is a descendant of a position:sticky element, we don't yet handle the case.

I have retested this issue due to re-triage of open bugs. I can't see a noticeable difference between how Firefox or Chrome changes the image/page after clicking the "Next >" button on Imgur. I would like to make sure this bug is valid, provide correct Status Tracking flags, and (if the case) attempt a regression investigation.

Also, the one dependency this bug has is not yet being worked on, so the proposed fix is theoretically not yet covered.

@Bas Schouten, please answer some questions to clear up this report:

1. Do you still see this issue reproduce?
2. Which operation system and version are you running on?
3. Which version of Firefox are you running when seeing this issue reproduce?
4. How exactly did you deduce the issue? How exactly do you observe Firefox to be slower?

(In reply to Bodea Daniel [:danibodea] from comment #6)

I have retested this issue due to re-triage of open bugs. I can't see a noticeable difference between how Firefox or Chrome changes the image/page after clicking the "Next >" button on Imgur. I would like to make sure this bug is valid, provide correct Status Tracking flags, and (if the case) attempt a regression investigation.

Also, the one dependency this bug has is not yet being worked on, so the proposed fix is theoretically not yet covered.

@Bas Schouten, please answer some questions to clear up this report:

1. Do you still see this issue reproduce?
2. Which operation system and version are you running on?
3. Which version of Firefox are you running when seeing this issue reproduce?
4. How exactly did you deduce the issue? How exactly do you observe Firefox to be slower?

Yeah, tried 3 different profiles comparing Chrome Canary to nightly, jank is pretty obvious in a profile too:

Firefox Nightly: https://share.firefox.dev/2MZKzu9
Chrome Canary: https://share.firefox.dev/3a8RaLK

Chrome seems to remain smooth in the animation even when it has long main thread janks. Matt, maybe you have an idea here? Are they somehow doing stuff async that we're not?

Yes, they're using OMTA for the transform animation and we're not. Hiro gave the reason for that in comment 5: the element with the animation is a large element (which we can't prerender in its entirety) and it is inside a position:sticky element, which is an unhandled case (bug 1642547) of partial prerender.

Bas, can you please retest using the current release (Fx105) and report here if the behavior remains? I tried it, and I'm not seeing the jank in the sidebar as I scroll and pause on entries.

Not sure if it is the same animation issue but Firefox is using 100% CPU browsing imgur.com and this is not new for me. I've been swtiching to Chrome just for browsing imgur.com for many years.

https://share.firefox.dev/3yFpbiD

(In reply to Ufku from comment #10)

Not sure if it is the same animation issue but Firefox is using 100% CPU browsing imgur.com and this is not new for me. I've been swtiching to Chrome just for browsing imgur.com for many years.

https://share.firefox.dev/3yFpbiD

This looks like a different issue. Your profile shows long delays in running JavaScript on the page; not a rendering issue.

Which means you should file a new bug and link that profile.

Bas, reopen if you still see this.