550346 - Horribly slow resizing of page by dragging lower right corner

Status: NEW

(Core :: Layout, defect)

Description

[Damon Sicore (:damons)]

Steps to reproduce:

1) Go to http://en.wikipedia.org/wiki/Che_Guevara

2) Click and drag the lower right-hand corner to resize.

Expected results:  Quick and snappy resizing of the window.

Actual results:  Window hangs for long periods of time while resizing.  Both Chrome and Safari are very responsive.

Comment 1

[Boris Zbarsky [:bzbarsky]]

fwiw, I tried turning off reflow interruption and that had no effect.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So unsuprisingly, 90% of the time is under reflow.  In fact, it's almost all under ReflowFloat, but I'm not sure whether that's many different floats or one float that contains the whole page.

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, 90% of reflow time is under nsColumnSetFrame::ReflowChildren.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  So the "References" are columnated in both Safari and Gecko.  But the "Notes" are only columnated in Gecko.  Changing the "Notes" to not use columns speeds things up tremendously.

Relevant markup for "Notes":

  <div 
    class="references-small references-column-count references-column-count-2"
    style="-moz-column-count:2; column-count:2;">

Relevant markup for "References":

  <div
     class="references-small"
     style="-moz-column-width:30em; -webkit-column-width:30em;
            column-width:30em;margin-left:1.5em;">

So the reason you see a difference in Chrome/Safari is that they're doing totally different work.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Just the notes div

Even resizing this is already slow on my machine.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So I'm seeing lots of calls to nsColumnSetFrame::ReflowChildren for each call to nsColumnSetFrame::Reflow.  "lots" == 11 so far on this Reflow call.

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** DONE PASS feasible=1
*** nsColumnSetFrame::Reflow balancing knownInfeasible=229199 knownFeasible=231480

231480-229199 = 2281.

Then we proceed to binary search for the correct height:

*** nsColumnSetFrame::Reflow balancing choosing next guess=230940
*** nsColumnSetFrame::Reflow balancing choosing next guess=230069
*** nsColumnSetFrame::Reflow balancing choosing next guess=230939
*** nsColumnSetFrame::Reflow balancing choosing next guess=230504
*** nsColumnSetFrame::Reflow balancing choosing next guess=230721
*** nsColumnSetFrame::Reflow balancing choosing next guess=230612
*** nsColumnSetFrame::Reflow balancing choosing next guess=230558
*** nsColumnSetFrame::Reflow balancing choosing next guess=230531
*** nsColumnSetFrame::Reflow balancing choosing next guess=230517
*** nsColumnSetFrame::Reflow balancing choosing next guess=230524
*** nsColumnSetFrame::Reflow balancing choosing next guess=230520
*** nsColumnSetFrame::Reflow balancing choosing next guess=230518
*** nsColumnSetFrame::Reflow balancing choosing next guess=230519

Then we do one final reflow pass at the end.  So we do 13 or so reflows here.

I haven't checked whether we hit the maybeContinuousBreakingDetected case here.

So obvious things to think about:

1)  Do we have to get the balancing layout correct down to the twip?  Could we
    stop once we're within 1 CSS px?  That would cut out about 6 reflows, right?
2)  Right now every single one of these rebalancing reflows is a full dirty
    reflow.  Do we really need that?  Not doing that would speed things up a
    good bit, I bet.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, nixing the AddStateBits(NS_FRAME_IS_DIRTY) that we do right before the ReflowChildren makes things a lot better (not perfect, but better).  roc, why do we need that bit there?

Comment 9

[Boris Zbarsky [:bzbarsky]]

In particular, shouldn't all the balancing reflows be basically resize reflows?  So we should be _removing_ (temporarily) NS_FRAME_IS_DIRTY even if it's set, not additionally setting it.  At least as far as I can see.