Closed Bug 1159470 Opened 10 years ago Closed 4 years ago

treeherder layout seems to be doing a bunch of relayout for scrollframes

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox40 --- affected

People

(Reporter: bzbarsky, Unassigned)

References

Details

STEPS TO REPRODUCE: 1) Load http://treeherder.mozilla.org/ 2) Scroll down to the bottom. 3) Click the "50" button to load more results. 4) Open the web console. 5) Run this script: document.documentElement.style.display = "none"; document.body.offsetWidth; var start = new Date; document.documentElement.style.display = ""; getComputedStyle(document.documentElement).color; var mid = new Date; document.body.offsetWidth; console.log("Style: " + (mid - start) + "\nLayout: " + (new Date - mid)); We spend a lot of time on layout here. Under ProcessReflowCommands, 34% of the time is under nsHTMLScrollFrame::ReflowContents (for some flex item) which breaks down as 21% TryLayout and 13% ReflowScrolledFrame calls. Of course under TryLayout there is also ReflowScrolledFrame. Not really sure what's going on there... esp since the profile under ReflowScrolledFrame shows a bunch of time in GetStyleDisplay under ReflowBlockFrame, and some self time in nsBlockFrame::ReflowDirtyLines... plus some self time in nsHTMLReflowState::InitConstraints and the frame property deletions InitOffsets does. Seems a bit weird. :(
(I spun off bug 1159819 to cover flexbox inefficiencies, so this bug can be focused on scrollframe stuff. If it all turns out to be the same issue, we can dupe as-needed.)
Flags: needinfo?(dholbert)

Per bug 1159819 comment 6, it seems this has gotten quite a bit better, and we're also faster than Chrome now (on comment 0's STR), by my measurement at least.

So I think we can call this WORKSFORME.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.