The default bug view has changed. See this FAQ.

Do not create container layers for scrollboxes with (0, 0) scrollRange

RESOLVED FIXED in mozilla6

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: stechz, Assigned: stechz)

Tracking

({mobile, perf})

Trunk
mozilla6
mobile, perf
Points:
---

Firefox Tracking Flags

(firefox5-)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
For remote builds, we are currently creating (empty) container layers for scroll frames that have a (0, 0) scroll range. I've noticed a lot of these in my testing, so we could cull many useless container layers.
(Assignee)

Comment 1

6 years ago
Created attachment 525701 [details] [diff] [review]
Do not create container layers for scrollboxes with (0, 0) scrollRange
Attachment #525701 - Flags: review?(roc)
Attachment #525701 - Flags: review?(roc) → review+
(Assignee)

Comment 2

6 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/a6467a88b056
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Assignee: nobody → ben
Keywords: mobile, perf
Target Milestone: --- → mozilla6
(Assignee)

Comment 3

6 years ago
This may fix a Talos regression from 642246.
tracking-firefox5: --- → ?

Comment 4

6 years ago
Before we can consider this, how big is the regression and is it definitely solved by this patch?
(Assignee)

Comment 5

6 years ago
We saw a Tp4 increase 9.69% on Nokia n900 mobile, but couldn't verify that this was a regression on Android devices. Mark said that an improvement occurred in a changeset range that included this bug and a cedar merge.

It's low risk patch, but then again, we're not very confident that there was a real Android regression or that this is the patch that fixed it.
Given the lack of obvious gain here we'll wait for 6 to get this. If there's a significant provable benefit here on a tier 1 platform then please renominate.
tracking-firefox5: ? → -
You need to log in before you can comment on or make changes to this bug.