Chris Waterson wrote: > 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 > >
it would be great if there is a win32 build on the ftp server to make testing & providing feedback easier.
