Closed
Bug 649666
Opened 13 years ago
Closed 13 years ago
Do not create container layers for scrollboxes with (0, 0) scrollRange
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
mozilla6
Tracking | Status | |
---|---|---|
firefox5 | - | --- |
People
(Reporter: stechz, Assigned: stechz)
Details
(Keywords: mobile, perf)
Attachments
(1 file)
1.23 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
Attachment #525701 -
Flags: review?(roc)
Attachment #525701 -
Flags: review?(roc) → review+
Assignee | ||
Comment 2•13 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/a6467a88b056
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Assignee | ||
Comment 3•13 years ago
|
||
This may fix a Talos regression from 642246.
tracking-firefox5:
--- → ?
Comment 4•13 years ago
|
||
Before we can consider this, how big is the regression and is it definitely solved by this patch?
Assignee | ||
Comment 5•13 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.
Comment 6•13 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•