Horribly slow resizing of page by dragging lower right corner

NEW
Unassigned

Status

()

Core
Layout
8 years ago
8 years ago

People

(Reporter: damons, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.
fwiw, I tried turning off reflow interruption and that had no effect.
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.
OK, 90% of reflow time is under nsColumnSetFrame::ReflowChildren.
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.
Created attachment 430641 [details]
Just the notes div

Even resizing this is already slow on my machine.
So I'm seeing lots of calls to nsColumnSetFrame::ReflowChildren for each call to nsColumnSetFrame::Reflow.  "lots" == 11 so far on this Reflow call.
*** 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.
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?
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.
You need to log in before you can comment on or make changes to this bug.