Closed Bug 100585 Opened 23 years ago Closed 9 years ago

don't position views during first-pass reflow

Categories

(Core :: Web Painting, defect, P2)

Product:
Core
Component:
Web Painting
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: waterson, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [reflow-refactor])

Is the block code is currently positioning frame views during first-pass table and box reflow? If so, this is wasteful because these unconstrained reflows are used for the purpose of constraint computation only. Investigate if this is actually happening, and if so, what its cost is. (Maybe just remove _all_ view positioning to get an upper bound on its cost per jrgm's tests or iBench.)
Status: NEW → ASSIGNED
Keywords: perf
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
Blocks: 103670
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Shuffling bugs around sabbatical. Will evaluate again on return.
Target Milestone: mozilla0.9.8 → Future
Has there been any findings in the meantime?
Whiteboard: [reflow-refactor]
So... Does FinishReflowChild need to be called during the first-pass reflow? Should we just not deal with this and focus on moving to an arch where the pref size is gotten by asking for it, not by reflowing?
Component: Layout → Layout: View Rendering
I'm not sold on this idea of separating out preferred-size calculation from reflow. It seems that a lot of preferred-size calculations require reflow.
Reassigning to core.layout@bugs
Assignee: waterson → core.layout
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Assignee: layout → nobody
QA Contact: chrispetersen → layout.view-rendering
Very few frames have views these days so I don't think there is anything to optimize here.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.