sounds like a very good thing ahmed k
"Markus H�bner" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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. > >
