Closed
Bug 584282
Opened 14 years ago
Closed 14 years ago
Speed up display list stuff
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: roc, Assigned: roc)
Details
Attachments
(2 files)
123.46 KB,
patch
|
tnikkel
:
review+
dbaron
:
approval2.0+
|
Details | Diff | Splinter Review |
53.84 KB,
patch
|
tnikkel
:
review+
dbaron
:
approval2.0+
|
Details | Diff | Splinter Review |
We call aBuilder->ToReferenceFrame(mFrame) a lot, like on every GetBounds(). This traverses frames all the way up to the display root, every time. Instead, we should compute aBuilder->ToReferenceFrame(mFrame) once, on display item construction, and use the cached result afterwards.
Assignee | ||
Comment 1•14 years ago
|
||
Mostly just adding nsDisplayListBuilder* parameters to constructors, so that the nsDisplayItem constructor can initialize mToReferenceFrame.
Attachment #462689 -
Flags: review?(tnikkel)
Assignee | ||
Comment 2•14 years ago
|
||
Attachment #462690 -
Flags: review?(tnikkel)
Comment 3•14 years ago
|
||
Comment on attachment 462689 [details] [diff] [review] Part 1: Add nsDisplayItem::ToReferenceFrame NS_ENSURE_SUCCESS(rv, rv); rv = aLists.Outlines()->AppendNewToTop(new (aBuilder) - nsDisplayXULDebug(this)); + nsDisplayXULDebug(Builder this)); NS_ENSURE_SUCCESS(rv, rv); You successfully compiled this after fixing this part, right?
Attachment #462689 -
Flags: review?(tnikkel) → review+
Comment 4•14 years ago
|
||
Comment on attachment 462690 [details] [diff] [review] Part 2: Convert code to use nsDisplayItem::ToReferenceFrame Is this going to make it harder if we keep around display lists?
Attachment #462690 -
Flags: review?(tnikkel) → review+
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #3) > You successfully compiled this after fixing this part, right? Yes, but that code is in DEBUG_LAYOUT which is not usually defined. I fixed the error though. (In reply to comment #4) > Is this going to make it harder if we keep around display lists? No. If we ever do keep around display lists, we'll still be rebuilding them from scratch every time we need a new one. In any case, I doubt we will keep around display lists per se. The approach I'm pursuing for invalidation is to record salient information from old display lists in FrameLayerBuilder::DisplayItemData.
Whiteboard: [needs landing]
Assignee | ||
Updated•14 years ago
|
Attachment #462689 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
Attachment #462690 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs approval]
Attachment #462689 -
Flags: approval2.0? → approval2.0+
Attachment #462690 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs approval] → [needs landing]
Assignee | ||
Comment 6•14 years ago
|
||
I landed this, but backed it out in case it was responsible for test failures. But it wasn't guilty (reproduced test failures on try server without this patch). However, it might be responsible for Txul regression on Mac 10.5.8 so we shouldn't reland until that's checked (hard to believe though).
Whiteboard: [needs landing]
Comment 7•14 years ago
|
||
Would be nice to get this landed, might help with 130078 perf.
Assignee | ||
Comment 8•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/f5d647210dec http://hg.mozilla.org/mozilla-central/rev/a3bcab53ea0d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•