Affected platforms:
Windows 10

Affected versions:
Nightly 90.0a1

Steps to reproduce:

1. Launch Firefox.
2. Access this link and initiate downloading 5 files (only completely download 2 of them).
3. Open the downloads panel and click on the ">" to open the Downloads Details panel.
4. Return to the Downloads Panel by clicking the "<"button.

Expected Results:
The transition from one download panel to the next one should be smooth.

Actual Results:
The transition from the Downloads Panel to the Downloads Details Panel is not done very smoothly. Please see the screencast for more details.

Notes:
Graphics card: Intel(R) HD Graphics 530.
The issue is reproducible only on the latest Nightly since the Downloads Details panel is not available on the other Firefox versions.
The issue is reproducible regardless if Proton is on or off.

Are other subviews smoother on your system? for example there should be one in the identity panel, or the Library button.
Just to understand if this is a specific problem of this panel or a more general problem with this transition.

(In reply to Marco Bonardo [:mak] from comment #1)

Are other subviews smoother on your system? for example there should be one in the identity panel, or the Library button.
Just to understand if this is a specific problem of this panel or a more general problem with this transition.

After placing the Library button on the Tabs bar, I'm seeing a similar behavior also when clicking the Bookmarks subview.

Ok, so this is a more global problem with panelmultiview animation being janky.

Can you provide a performance profile of the animation on your machine from the Firefox profiler? ( https://profiler.firefox.com/ )

Does turning webrender on/off make a difference?

(In reply to :Gijs (he/him) from comment #4)

Can you provide a performance profile of the animation on your machine from the Firefox profiler? ( https://profiler.firefox.com/ )

Does turning webrender on/off make a difference?

Yes, the transition between the downloads panel subview is a lot smoother when web render is turned off (used the preference gfx.webrender.force-disabled=true)
Here is a Firefox profiled with web render ON: https://share.firefox.dev/3eiD6S4
Here is a Firefox profile with web render OFF: https://share.firefox.dev/3b3msnd

(In reply to Simona Badau from comment #5)

(In reply to :Gijs (he/him) from comment #4)

Can you provide a performance profile of the animation on your machine from the Firefox profiler? ( https://profiler.firefox.com/ )

Does turning webrender on/off make a difference?

Yes, the transition between the downloads panel subview is a lot smoother when web render is turned off (used the preference gfx.webrender.force-disabled=true)
Here is a Firefox profiled with web render ON: https://share.firefox.dev/3eiD6S4
Here is a Firefox profile with web render OFF: https://share.firefox.dev/3b3msnd

Thanks. I gotta be honest, I'm not able to deduce much from these profiles that would explain additional jankiness / dropped frames. Florian, what about you - or can you recommend someone from the graphics team who could take a look?

(In reply to :Gijs (he/him) from comment #6)

(In reply to Simona Badau from comment #5)

(In reply to :Gijs (he/him) from comment #4)

Can you provide a performance profile of the animation on your machine from the Firefox profiler? ( https://profiler.firefox.com/ )

Does turning webrender on/off make a difference?

Yes, the transition between the downloads panel subview is a lot smoother when web render is turned off (used the preference gfx.webrender.force-disabled=true)
Here is a Firefox profiled with web render ON: https://share.firefox.dev/3eiD6S4
Here is a Firefox profile with web render OFF: https://share.firefox.dev/3b3msnd

Thanks. I gotta be honest, I'm not able to deduce much from these profiles that would explain additional jankiness / dropped frames. Florian, what about you - or can you recommend someone from the graphics team who could take a look?

When looking at the renderer thread of the GPU Process on the profiler with webrender enabled (https://share.firefox.dev/3vLeBCD), I see we have Composite markers at 60Hz, but I see no "NumDrawCalls" markers during the animation, and there's a single "CompositorScreenshot" marker during all this time.

Markus, could you please have a look at the profile, and see if there's someone who should be needinfo'ed? Thanks!

Forgot to add the needinfo flag, see comment 7.

It looks like the off-main-thread transform animation isn't running when WR is used - the composites are triggered but they don't detect a difference and then don't render anything.

This is a partial prerender case and it seems once after we detected a jank on the transfrom animation, we fails to notify the jank animation to the main thread here. It looks like in the popup panel case, the LayersId is mRootLayerTreeID but we don't have mLayerManager. I wonder how we can get the corresponding PCompositorBridgeParent for the popup case?

Anyways, it's an issue in partial prerender stuff and it's been disabled both on beta/release channels.

CCing sotaro, he probably knows CompositorBridge and relevant structures.

Part of the problem seems similar to Bug 1701451. It is going to be addressed by Bug 1709998.

Can you check if this has improved on today's nightly, now that bug 1709998 is fixed?

(In reply to :Gijs (he/him) from comment #13)

Can you check if this has improved on today's nightly, now that bug 1709998 is fixed?

I can see an improvement in the Bookmarks and History panels but not in the Downloads panels. Please see - https://imgur.com/pCnwnsg

Profile of Downloads panels.
https://share.firefox.dev/3orP13l

I've locally haven a patch to fix this, but I am supposing there are more reasonable/better ways to handle this case. (I'd want someone who is familiar with the relationship between CompositorBridge{Parent,Child} to take a look at this issue)

The patch addressed the problem for me.

but I am supposing there are more reasonable/better ways to handle this case.

:hiro, do you have any ideas about better ways to handle this case?

As you can see the patch, the patch introduces another if (const LayerTreeState* state = GetIndirectShadowTree(layersId)) block in the function, I suppose we can unify both if blocks in the function somehow, but I have no idea. Anyways, the part we need to fix is the NotifyJankedAnimations function.

I looked into the patch. It could be simpler.

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

:hiro, can you take this bug for creating a test for this bug? Thanks.

• https://phabricator.services.mozilla.com/D115470#3769266

I managed to write a browser mochitest for this issue, will post it.

https://hg.mozilla.org/mozilla-central/rev/c84629c7d160
https://hg.mozilla.org/mozilla-central/rev/61c572d87d16

Verified as fixed using the latest Nightly 92.0a1 and Firefox 91 beta 8 on Windows 10 x64.