Hey, I've been building on rjesup and shaver's stuff for optimizing
incremental reflow, especially for DHTML,
<http://bugzilla.mozilla.org/show_bug.cgi?id=129115>.
I've got stuff to a point where I think we should consider it.
The current implementation of incremental reflow involves a queue of
reflow commands that are individually dispatched to their target frames.
Each dispatch involves a complete recursive descent to the target frame
to recover reflow state, followed by unwinding and propagation of reflow
damage to the rest of the frame hierarchy. If you have ten reflow
commands enqueued, we perform ten individual incremental reflows. This
is fairly expensive, because you must pay the cost of recovering reflow
state and propagating reflow damage for each reflow command.
The new implementation (due to rjesup) processes _all_ of the pending
reflow commands at once by using a tree (rather than a list) to
represent the path that that incremental reflow must follow.
Specifically, at each articulation point in the incremental reflow where
we'd normally pull off the next single frame from the list, we must now
assume that there could be multiple children that need reflow. The
details are dry, and fairly mechanical, but I've put them in the bug.
(One note: I was able to eliminate the table timeout reflow stuff.)
I'm currently putting this stuff on a branch (REFLOW_20020412_BRANCH) so
it's easier to test and evaluate.
thanks,
chris
