Closed Bug 271927 Opened 15 years ago Closed 13 years ago

nsAbsoluteContainingBlock::IncrementalReflow calls ReflowAbsoluteFrame twice

Categories

(Core :: Layout: Positioned, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: mats, Unassigned)

References

Details

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

nsAbsoluteContainingBlock::IncrementalReflow calls ReflowAbsoluteFrame twice.
This bug is followup from bug 201897:

 ------- Additional Comment #31 From Mats Palmgren  2004-10-03 18:00 PDT
A note on the existing code:
I'm surprised that nsAbsoluteContainingBlock::ReflowAbsoluteFrame
is called twice for every nsAbsoluteContainingBlock::IncrementalReflow
(which means we will reflow shrink-to-fit boxes four times).
Is there a reason for this?


------- Additional Comment #33 From Boris Zbarsky  2004-10-03 18:16 PDT 
> I'm surprised that nsAbsoluteContainingBlock::ReflowAbsoluteFrame
> is called twice

The first call is because we have a reflow command for the absolute list
(reflows all dirty absolute frames) and the second is because the reflow path
contains one of our child frames, right?  Could we flip those two chunks around?
 Presumably any frames we flow because they're in the reflow path would get
marked clean after the reflow and we wouldn't flow them twice?  Would that screw
up the eReflowReason_Initial twiddling in the dirty block, though?

Alternately, could we prune frames we reflow because they're dirty from the path
so that they're ignored in the second block?
roc, any thoughts on this?
Not off the top of my head. What you suggest should be workable.
Whiteboard: [reflow-refactor]
Blocks: 203448
Blocks: 317561
This code went away with the reflow branch.  The new code doesn't have this problem.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.