Open Bug 1548683 Opened 6 years ago Updated 1 year ago

Preloaded new tab page thinks it's visible and redraws when the window is resized

Categories

(Firefox :: New Tab Page, defect, P3)

defect

Tracking

()

Tracking Status
firefox68 --- affected

People

(Reporter: mstange, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, perf:resource-use, power)

Profile: https://perfht.ml/2ZOC6eV

Steps to reproduce:

  1. Create a new profile.
  2. Navigate to https://profiler.firefox.com/ , close all other open tabs.
  3. (Optional: Install and start the Gecko Profiler add-on.)
  4. Resize the browser window
  5. (Optional: Grab a profile.)

Expected results:
Only the browser window document and the foreground tab should be painted during the resize.

Actual results:
The profile shows painting in the Privileged Content process, repainting about:newtab. about:newtab is not visible.

The priority flag is not set for this bug.
:tspurway, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(tspurway)
Component: New Tab Page → Activity Streams: Newtab
Flags: needinfo?(tspurway)

This is kind of intended. The new tab page that is pre-rendered will also be resized in the background. If there are perf issues, however, we could debounce these resize operations to happen after the user is done resizing.

Flags: needinfo?(mstange)

I see. So there are two parts that happen during resizing: 1. Reflow at the new size, and 2. Rendering / rasterization.
Doing 1 is fine. I'm more concerned about 2. Having the rasterized content around at all times also takes up quite a bit of memory, at least with non-WebRender.

If about:newtab were not preloaded at all, opening a new tab would take up time in the following stages: 1. Pageload, 2. JavaScript execution / DOM "render", 3. Layout, 4. Paint. Preloading it in an "inactive" tab would prepare 1-3, but leave 4 to happen at the time that the tab is actually opened. Preloading it in an "active" tab (which seems to be what's happening now) prepares all 1-4; so it saves the painting time but pays the painting memory cost.

Do you know which bug made the change to have it pre-rendered? I'm curious about the performance considerations that went into it.

Flags: needinfo?(mstange)

Looks like bug 791670 is where most of the work to have the page preloaded by default. The main desire is to make the page appear immediately ready when the user opens a new tab.

I wonder if something simple like setting the page to opacity: 0 could avoid paint without affecting layout (so not display: none)

The priority flag is not set for this bug.
:tspurway, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(tspurway)
Flags: needinfo?(tspurway)
Priority: -- → P3
Component: Activity Streams: Newtab → New Tab Page
No longer blocks: pocket-newtab
Severity: normal → --
You need to log in before you can comment on or make changes to this bug.