Closed Bug 1731009 Opened 1 month ago Closed 1 month ago

With fission enabled, the demo on https://codepen.io/amit_sheen/pen/PojjzjB stutters (throttles?) unless you continuously move the mouse inside the demo pane

Categories

(Core :: Layout, defect, P2)

defect

Tracking

()

VERIFIED FIXED
94 Branch
Fission Milestone MVP
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox92 --- wontfix
firefox93 --- wontfix
firefox94 --- verified

People

(Reporter: mayankleoboy1, Assigned: hiro)

References

(Regression, )

Details

(Keywords: perf, regression, Whiteboard: fission-hard-blocker)

Attachments

(2 files)

  1. Enable Fission (either via the fission.autostart pref, or via Nightly experiments)
  2. Go to https://codepen.io/amit_sheen/pen/PojjzjB

AR: The demo is stuttery. Now start moving the mouse inside the demo pane. The demo will become very smooth.

Note that while the demo is stuttering, the CPU use is not high, which would imply some sort of throttling?

This is not a recent regression. A build from Jun-2020 also shows this behaviour.

If you export the demo to your local machine and run the demo from there, there is no stuttering.
Edit: I dont know if this is a known bug or not. In any case, feel free to WONTFIX or Dupe

Summary: With fission enabled, the demo on https://codepen.io/amit_sheen/pen/PojjzjB stutters unless you continuously move the mouse inside the demo pane → With fission enabled, the demo on https://codepen.io/amit_sheen/pen/PojjzjB stutters (throttles?) unless you continuously move the mouse inside the demo pane
Fission Milestone: --- → ?
Component: General → Performance

The animation is janky for me with or without Fission. The animation oscillates between smooth and janky every few seconds. I can't tell whether enabling Fission or moving the mouse makes any difference. I recorded two performance profiles:

Profile with Fission disabled:
https://share.firefox.dev/2XqpLRD

Profile with Fission enabled:
https://share.firefox.dev/2VLcIJR

For some reason the profile with Fission disabled doesn't include the GPU process, even though I see a GPU process listed in about:processes.

Here is a profile with Fission enabled : https://share.firefox.dev/3hE7dEy

In this, i kept the mouse stationary for the first 5 seconds, and then started moving it inside the animation/demo pane after the 5 second mark
Edit: The above profile is from a different demo by the same author : https://codepen.io/amit_sheen/pen/mdwqXEv

(In reply to Mayank Bansal from comment #4)

Edit: The above profile is from a different demo by the same author : https://codepen.io/amit_sheen/pen/mdwqXEv

Thanks for the second test case. I can reproduce the problem very clearly with that "Daily Planet" test case:

  • With Fission disabled, the animation is always smooth.
  • With Fission enabled, the animation is choppy when the mouse pointer is not moving and smooth when I move the mouse pointer rapid over the animation.

Here are my profiles of the Daily Planet demo. In each profile, I kept my mouse still for the first five seconds and then moved the mouse pointer rapidly over the animation for the next five seconds.

Profile with Fission disabled:
https://share.firefox.dev/2XlkJWp

Profile with Fission enabled:
https://share.firefox.dev/2XA2Gw8

This is not a recent regression because I can also reproduce this bug in Firefox 92 and Beta 93.

Gnome Xwayland, Debian Testing, Intel
MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 2019-06-25 --bad 2020-03-01 --pref gfx.webrender.all:true fission.autostart:true -a https://codepen.io/amit_sheen/pen/PojjzjB

6:34.42 INFO: Last good revision: 26711f10f5f45471b5856fb5cef08948f0e5bc21 (2019-09-11)
6:34.42 INFO: First bad revision: f60e7f5f8557d4f385cb182a995fb537f2cb7611 (2019-09-12)
6:34.42 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=26711f10f5f45471b5856fb5cef08948f0e5bc21&tochange=f60e7f5f8557d4f385cb182a995fb537f2cb7611

Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: perf, regression
OS: Unspecified → All
Hardware: Unspecified → All

In that range, it could be bug 1541705, bug 1580063 or bug 1574493.

Hiro, can you take a look? The refresh ticks on the main thread are skipped because we think the compositor is running the animation, but the compositor isn't advancing the animation (or WR somehow ignores the animations effects), it seems.

Flags: needinfo?(hikezoe.birchill)

Yeah, bug 1541705 is the culprit. In the test case in comment 0, this aFrame->GetRelativeToSelf() returns an empty rect, that's the cause.

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Regressed by: 1541705

This is a bad bug. Tracking for Fission MVP.

Severity: -- → S3
Fission Milestone: ? → MVP
Component: Performance → Layout
Priority: -- → P2
Whiteboard: fission-hard-blocker

Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.

Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].

The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, display: grid, etc. generate (0x0) sized frame even if decendants have
sized.

[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094

Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4256690c306d
Properly check whether the given nsIFrame is inside an OOP Iframe visible rect or not even if the frame size is (0x0). r=tnikkel
Flags: needinfo?(hikezoe.birchill)
Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ae9abfaa385d
Properly check whether the given nsIFrame is inside an OOP Iframe visible rect or not even if the frame size is (0x0). r=tnikkel
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch

This is fixed. Thanks!

Flags: needinfo?(hikezoe.birchill)

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(hikezoe.birchill)

:hiro, is this bug important enough to require an uplift?

If this bug only affects Fission users, then we don't need to uplift to Beta 93. We don't plan to run any Fission experiments in Release 93, so no users would be affected.

Thank you Chris for the current Fission plan. The patch only affects OOP iframe cases.

Flags: needinfo?(hikezoe.birchill)
Flags: qe-verify+

Confirmed issue with 94.0a1 Build ID 20210915152638.
Verified patch with 94.0b2

Based on Comment 20, I'm marking this issue as Verified Fixed.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.