1846559 - Firefox takes 1.5x time as Chrome in paint on several TodoMVC-*-Complex-DOM tests in speedometer3

Status: NEW

(Core :: Web Painting, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Nightly (July 11) https://share.firefox.dev/43Qy05N
7506 Nightly vs 4505 Chrome samples

https://speedometer-preview.netlify.app/?developerMode=#home

Comment 1

[Brian Grinstead [:bgrins]]

Permalink for the test at of today https://64bfff5ed4ccda0008b38414--speedometer-preview.netlify.app/?suite=TodoMVC-React-Complex-DOM

Comment 2

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

The severity field is not set for this bug.
:tlouw, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Markus Stange [:mstange]]

Here's a slightly massaged profile of just the display list building part: https://share.firefox.dev/47ECsYv
A fair amount of time is spent in nsHTMLScrollFrame::GetScrollRange. If we can stop snapping the scroll range (because we'll snap the scroll position at WR frame build time instead of at display list build time), the time spent in that function will be reduced considerably.

There are probably other things to find in that profile.

Comment 4

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #3)

A fair amount of time is spent in nsHTMLScrollFrame::GetScrollRange.

I've broken this out into bug 1850824.

Comment 5

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

The severity field is not set for this bug.
:tnikkel, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Markus Stange [:mstange]]

Updated profile: https://share.firefox.dev/3ZgYXyY

DecideScrollableLayer is still taking 12% of the Paint time.

Comment 7

[Timothy Nikkel (:tnikkel)]

Thanks for that profile.

nsLayoutUtils::AsyncPanZoomEnabled I think can only be false if we are inside a popup? So everything in a content process should always be getting true for that and we don't have to do the more complicated things taking time in that function.

nsHTMLScrollFrame::WantAsyncScroll checks if the visual and layout scroll range differ, but those can only differ if there is zooming, which can only happen on the root content root scroll frame, so most of the time that's a waste.

But also getting the layout scroll range and the visual scroll range computes the scrolled rect once for each, we should just compute it once and use it for both.

GetOffsetTo (the reference frame) is also showing up taking time. I think that during painting we cache that value so we should just hook into that cache.

Comment 8

[Timothy Nikkel (:tnikkel)]

Expanding the range of that profile there to look at the GetScrolledRect time outside of painting.

I think there might be duplicate calls to GetScrolledRect (via different paths) in nsHTMLScrollFrame::ReflowFinished.

Getting the reference frame is slow, IsPreserve3DLeaf is one thing slow doing that. I think we can microoptimize that function: nsIFrame::Combines3DTransformWithAncestors calls GetClosestFlattenedTreeAncestorPrimaryFrame (which is slow) and then |return IsCSSTransformed() || BackfaceIsHidden()|, both of those should be fast, so switching the order of those should be a good win.

But also I think we should be able to cache the reference during reflow for any repeated calls.

Comment 9

[Timothy Nikkel (:tnikkel)]

During reflow, but after we reflow the scroll frame itself, we call GetScrolledRect several times. Specifically

nsHTMLScrollFrame::Reflow calls
-nsHTMLScrollFrame::UpdatePrevScrolledRect
-nsHTMLScrollFrame::PostOverflowEvent (which calls GetOverflowState)

nsHTMLScrollFrame::DidReflow calls
-nsHTMLScrollFrame::NeedsResnap

nsHTMLScrollFrame::ReflowFinished calls
-nsHTMLScrollFrame::ScrollToImpl

nsLayoutUtils::ComputeScrollMetadata also calls GetScrolledRect more than once.

nsLayoutUtils::CalculateScrollableRectForFrame
mozilla::GetDisplayPortImpl calls nsLayoutUtils::CalculateExpandedScrollableRect

Comment 10

[Justin Link]

<re-focusing this bug, as per Markus' recommendation>

TodoMVC-React-Complex-DOM is no longer showing a significant difference between Firefox and Chrome in the "paint" bucket but some other TodoMVC tests are.

TodoMVC-Lit-Complex-DOM:
7262 vs 4786 samples (diff: 2476, 1.52x): Firefox profile vs Chrome profile + Chrome profile + Chrome profile
Making Firefox as fast as Chrome on this function would reduce its time by 6.6%.

TodoMVC-Preact-Complex-DOM:
7222 vs 5078 samples (diff: 2144, 1.42x): Firefox profile vs Chrome profile + Chrome profile + Chrome profile
Making Firefox as fast as Chrome on this function would reduce its time by 7.5%.

TodoMVC-Svelte-Complex-DOM:
7321 vs 5110 samples (diff: 2211, 1.43x): Firefox profile vs Chrome profile + Chrome profile + Chrome profile
Making Firefox as fast as Chrome on this function would reduce its time by 8.1%.