Open Bug 99219 Opened 23 years ago Updated 2 years ago

Investigate the possibility of not always computing the containing block's height in HTMLREflowState initialization

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: attinasi, Unassigned)

References

Details

(Keywords: perf) 

While working on bug 85016, the cost of computing the containing block's
computed height became high and we had to hack around it a bit and special-case
elements that are percentage-height in auto-height containers. There may be a
further optimization whereby we can eliminate the computation of the containging
block's size when the children do not need it. Something to look into anyway...
Keywords: perf
Target Milestone: --- → mozilla1.0.1
Accepting
Status: NEW → ASSIGNED
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
Blocks: 114584
In fact, would it make sense to make all sorts of computations in
nsHTMLReflowState lazy?  As long as we're careful not to introduce cyclical
dependencies...
Assignee: attinasi → misc
Status: ASSIGNED → NEW
Component: Layout → Layout: Misc Code
Priority: P1 → P2
QA Contact: cpetersen0953 → nobody
Target Milestone: Future → ---
Target Milestone: --- → Future
Assignee: layout.misc-code → nobody
QA Contact: nobody → layout.misc-code
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.