Spent the day looking through nsBlockFrame, trying to figure out how I'm going to fix bug 56854, which basically says that we go O(n²) when we have lots of blocks stacked up on top of each other thanks to RecoverStateFrom(). Started by trying to figure out how to do buster's BRS_ISINLINEINCRREFLOW more cleanly. This unfortunately, led me back to the fact that the regression tests are in a sorry, sorry state...

Landed a partial fix for bug 5569: we weren't triggering an initial reflow in some cases when a load was cancelled. There were lots of crawlies under that rock; turns out we'd broken the symmetry of OnStartRequest() and OnStopRequest() in nsURILoader along the way. I should probably file a separate bug on that issue.

Continued working through issues on the layout regression tests: I now have a set of patches (including some that are purportedly ``in Pavlov's tree'') that let us run successfully from front to back with only a handful -- a dozen or so -- false positives.

Landed fixes for bug 74728 (again), and bug 53956. The former was a problem with the nsFixedSizeAllocator landing from a couple of weeks ago. The later something I discovered while trying to get the layout regression tests up off the floor.

Still seeing some minor problems on the regression tests; e.g., the test case for bug 40129. This one has an unsized image, in a floater, inside a table cell. It appears that when the image is not in the cache, we end up collecting the regression data before the image size has arrived. I'm not sure why this happens...

Wasted more time looking at image loading issues. Think I cleaned up some of the stuff with the imgRequestProxy in bug 75576. Found another problem with OnStartDocumentLoad(), filed bug 75623, and pestered mscott about a review.

Circulated some minor nsBlockFrame refactoring and cleanup to rbs, roc, dbaron, attinasi, and karnaze for review. Forwarded some PresShell debugging goop to nisheeth and jst for review.

With respect to optimizing incremental reflow for very long block frames that contain blocks, dbaron suggested on IRC that optimizing RecoverVerticalMargins was a waste of time. (He'd like to change how we do margins altogether, I guess.)

Went through pierre's style sharing stuff. Marathon review.

Worked out a fix for bug 74184, which was happening because we were not correctly propagating the NS_FRAME_HAS_CHILD_WITH_VIEW state flag forward to new continuing frames.

More style sharing fun: caved in and gave an sr=, did some builds, some super-low-end performance testsing.

rfg came to town. Got his diffs onto STATIC_BUILD_20010418_BRANCH, and updated the bug.

Broke up recent block code cleanup into several mozilla-0.9.1 bugs: bite-sized pieces to review. Found and fixed a random crasher for mozilla-0.9. Fixed a bunch of problems on the STATIC_BUILD_20010418_BRANCH. Somehow all the files hadn't been checked in yesterday. Gave up on the view manager stuff; couldn't deal with the arrogance, so I made it roc's problem.

Pushed around a few bugs here and there. Found more weirdness in nsBlockFrame. Wallpapered over a top-crash. Spent an hour or so helping shaver debug stuff on the STATIC_BUILD branch.

Monday, April 23, 2001

Spent a little time cleaning up the STATIC_BUILD branch.

Started working on bug 56854 in earnest. This is the one where we go O(n²) in a bad way, mostly hurting from nsBlockReflowState::RecoverVerticalMargins(). I went ahead and broke out nsBlockReflowState into its own files (bug 77414) in the process.

Got a first-cut together at fixing 56854. Made it so that we avoid doing any state recovery by caching the nsBlockReflowState object's per-line data stuff. This was what Quantify pointed its finger at when I did a profile several weeks ago. Ironically, I think I've been snafu'd a bit, and Quantify made the problem out to be worse that it really is. On a fast machine, I suspect our timers don't fire often enough to exacerbate the O(n²) behavior of state recovery. In other words, the fast machine slurps up enough data that we don't need to do very many reflows. The problem is, when we're running under Quantify, the timers fire at the same rate, but the ``crippled'' binary does much less work per unit of time. This leads to more incremental reflows, which makes the O(n²) algorithm jump out. The bottom line is, on my fast machine, the hacked fix saves about a second, maybe two, out of twelve. On a slow machine (166MHz Win98 box), it drops the layout time from over 70s to about 50s. IE5 lays the page out in 11s.

Finished analysis of profile for bug 56854 and filed a bunch of follow-up bugs.

Dug into 77941, which is a spin-off from 56854 dealing with the eager initialization of the selection color stuff. Also dug into 77954, which deals with the creation of a bunch of :before pseudo-elements. I came up with an alternative to the implementation in quirk.css that's not as faithful to 4.x, but doesn't require creation of pseudo-content. Maybe Hixie can come up with something better.

Hixie helped me discover a bunch of vestigial code that mjudge had left in the tree back in February, 2000! This accounted for about 25% of the time spent creating pseudo-elements. Hixie also has some ideas about making the selector for the <dd> element better using :not.

Spent some time looking at The Worst Floater Bug (according to Hixie, anyway). I think the root of the evil starts with buster's fix to bug 38157. Specifically, I think he wallpapered over the real problem. I took the first simplified test case in that bug and removed the block from the second floater, along with his changes to PostPlaceLine() in nsBlockFrame, and no bug. So, I think what was really wrong in bug 38157 was shrink-wrapped blocks. I'll look more tomorrow.

Checked in miscellaneous block cleanup fixes.