0.4% of our entire Speedometer 3 time is spent in nsHTMLScrollFrame::GetScrolledRect: https://share.firefox.dev/3qRY7Me

This function is called both during display list building and during layout.

If we can stop snapping the scroll range, for example by not having display item coordinates move during scrolling (and thus causing WR to always snap the same way regardless of scroll position), then our sp3 score will benefit.

Most of the time is the transfrom getter. Can we snap the scrollrange assuming the transform scale is 1 always? We could still include the pinch zoom resolution. But is it a big deal if we don't include the transform scale?

Maybe Hiro can speak to comment 1. Is it just things like bug 1801098 that would happen for scrollframes that have a scale transform? Are there any other negative side effects?

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

Most of the time is the transfrom getter. Can we snap the scrollrange assuming the transform scale is 1 always? We could still include the pinch zoom resolution. But is it a big deal if we don't include the transform scale?

That's a great point. Yes, I think we can assume the transform scale is 1 always. When I originally wrote the snapping I wanted to never repaint for layer pixel alignment changes even if you scroll to the bottom of a scroll frame that's inside a scale transform, but that is such a rare case that we really shouldn't take a performance hit on everything to support it.

There's nothing I can do in addition to the Makus' comment. In my naive web experiences indeed scroll containers inside scale transform is probably rare.

Okay, I'll write up a patch for that and file a bug to get it landed.