2052240 - 5.48% tp5o_scroll (Windows) regression on Wed June 24 2026

Status: RESOLVED WONTFIX

(Core :: Panning and Zooming, defect)

Description

[Performance Sheriff Bot]

Perfherder has detected a talos performance regression from push 35e727d8fda22f3ccfcb1e620484f041002a63c0. As author of one of the patches included in that push, we need your help to address this regression.

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy.

Regression	Test	Platform	Options	Absolute values [old vs new]
5%	tp5o_scroll (doc)	windows11-64-24h2-shippable	e10s fission stylo webrender	0.91 -> 0.96

Support & Actionable Steps

For questions, please contact [e-mail]. You can also find help on Slack (#perf-help) or Matrix (#perftest).

Action guide details:

• See the guide to handling regression bugs for investigation steps.
• Review the alert summary for affected tests, graphs, and comparisons.
• Check the PerfCompare results.
• Tests on Try: Run all tests using ./mach try perf --alert 51160 (See documentation link for details).
• Profiling jobs: Trigger jobs from Treeherder job view or request them from [e-mail].

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2048146

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Okay the regressed test is an apz.paint_skipping.enabled=false test, and all regressed subtests are CSSOM ones, which means smooth scrolling tests, some of non-CSSOM ones, instant scrolling tests are improved.

I have a theory: In the case of CSSOM ones:

1. APZ drives the smooth scroll animation
2. Then APZ notifies each scroll offset to the main-thread via ScrollContainerFrame::ScrollToCSSPixelsForApz
3. It ends up reaching to this code block

nsPoint pt = ClampAndAlignWithLayerPixels(aPt, GetLayoutScrollRange(), aRange,
                                          curPos, appUnitsPerDevPixel, scale);
if (pt == curPos) {
  // Even if we are bailing out due to no-op main-thread scroll position
  // change, we might need to cancel an APZ smooth scroll that we already
  // kicked off. It might be reasonable to eventually remove the
  // mApzSmoothScrollDestination clause from this if statement, as that
  // may simplify this a bit and should be fine from the APZ side.
  if (mApzSmoothScrollDestination && !isForClamping) {
    if (aOrigin == ScrollOrigin::Relative) {
      AppendScrollUpdate(
          ScrollPositionUpdate::NewRelativeScroll(mApzScrollPos, pt));
      mApzScrollPos = pt;
    } else if (aOrigin != ScrollOrigin::Apz) {
      ScrollOrigin origin =
          (mAllowScrollOriginDowngrade || !isScrollOriginDowngrade)
              ? aOrigin
              : mLastScrollOrigin;
      AppendScrollUpdate(ScrollPositionUpdate::NewScroll(origin, pt));
    }
  }
  return;
}

With layout.disable-pixel-alignment=false (before 2048146), the pt value was rounded, so for example, given that APZ notifies 9.8' then '10.1', those value are rounded to 10`, thus it will skip calling a SchedulePaint() call. In other words with layout.disable-pixel-alignment=true, we don't basically skip calling a SchedulePaint().

I believe this difference caused the regression. Given that apz.paint_skipping.enabled=false is not our default, so I am going to close this bug as WONTFIX.

Note that someone might think that pt and curPos in the code block is app units, it's converted into double.