Yielding during layout

[Simon Fraser]

Is it me, or does layout now render almost the entire web page
in one pass? It used to be that we did multiple reflows when loading
a large page, which, although it could be slower, had the advantage
that we got back to the main event loop, and were able to process
user events, and throb the throbber.

Now when I load a large page (e.g. www.cnn.com), the entire app
halts until we've laid out most of the page contents. This causes
the throbber to throb very eratically, and interferes with
user interaction in other applications.

What's the deal here?

Simon

[Steve Clark]

I don't know of anything that's changed in layout with respect to
incremental page loading. Nisheeth? Chris?

Steve

[Chris Waterson]

The only thing that I can think of is that I set the default value for the
"back-off count" (which is really the "shut-off count") to "-1".

You can try changing this value in your preferences...

user_pref("content.notify.backoffcount", 3);

...to see if the problem "goes away". (What this means is that after three
reflows, the content sink will no longer trigger reflow at all; we'll wait until
the document has completed loading.)

chris

[Nisheeth Ranjan]

Asynchronous reflow during document load got pulled before beta 2 because
it caused the document's JS onload handlers to fire too early. Currently,
async reflow only happens after the document has loaded.

Rick Potts and I have talked about a solution that gives us async reflow
all the time and does not regress onload handlers. I will begin
implementing that this week.

Hopefully, once I've finished, the UI will become more responsive because
we'll return to the main event loop more often. Simon, could you please
email me the urls to the pages that currently lock up the UI for
unacceptable lengths of time? I'll use them as a test case as I work on
re-enabling async reflow. Thanks!

Nisheeth
--

[David Hyatt]

The primary reason that I've found for async reflow causing an early onload
firing is that the load of a subdocument (i.e., those found in iframes or
frames) is kicked off during reflow.

What I was seeing with XUL was that we construct frames synchronously in
response to insertions/additions, but the reflow of those frames happens
asynchronously. For images, the load is kicked off during frame construction,
so you're ok there, but for subdocuments, you get in trouble because the
reflow hasn't happened yet.

I wonder how many of the problems you were seeing would be fixed by the
HTMLFrameFrame.cpp code being restructured to kick off the load at frame
construction time rather than at reflow time...

waterson has the bug on this, but bugzilla is down right now, so I can't get
you a number.

dave
(hy...@netscape.com)

[Eric Pollmann]

Yes, this is exactly the solution that Rick Potts, Nisheeth and I came up with
when discussing the early onload problem before nsbeta2. Unfortunately, in the
frameset case, nsHTMLFrameOuter/InnerFrame's are not constructed until the reflow
of the containing nsHTMLFrameSetFrame. So, even moving the load up to
construction of nsHTMLFrameOuter/InnerFrame, it won't be fired and added to the
load group until the containing frameset gets a reflow, which is still after the
early onload fires.

Nisheeth and Rick have cooked up a much simpler solution to this problem, that
won't require rewriting all of nsHTMLFrame*Frame and particularly
nsHTMLFrameSetFrame::Reflow. :) Details coming shortly.

The related bug assigned to Waterson is:
http://bugzilla.mozilla.org/show_bug.cgi?id=49874

-Eric

[David Hyatt]

Keep me posted. I had to apply a liberal sprinkle of FlushPendingNotifications to
both XBL and XUL to make sure the onload handlers fired on time. I'd love to remove
those (assuming you get the load out of reflow).

:)

dave

[Nisheeth Ranjan]

The plan is to create a dummy layout channel, add it to the document load group at the
start of layout and remove it at the end of layout. This will ensure that the document
loader fires the OnEndDocumentLoad() notification only after layout is completely
finished. The dummy layout channel will also implement the Cancel() method which will
abort layout in case the document load is canceled by the user.

If you guys see any holes in this plan, please comment. Thanks!

Nisheeth
--

[Mike Pinkerton]

Nisheeth Ranjan wrote:
> Hopefully, once I've finished, the UI will become more responsive because
> we'll return to the main event loop more often. Simon, could you please
> email me the urls to the pages that currently lock up the UI for
> unacceptable lengths of time? I'll use them as a test case as I work on
> re-enabling async reflow. Thanks!

FWIW, this is now bug 50634

http://bugzilla.mozilla.org/show_bug.cgi?id=50634

A good test page is www.cnn.com which locks up a G4 450 for about 4-5 seconds.

--
Mike Pinkerton
Mac Browser Weenie
pink...@netscape.com http://people.netscape.com/pinkerton

[Vidur Apparao]

I first noticed the problem that Simon originally mentioned late last week - well
after the PR2 removal of async reflow. Turning Nisheeth's work back on will help
responsiveness, but I think it's a red herring with respect to the current
problem. Chris' suggestion of reverting his backoff count change might be a good
first shot at figuring out what's wrong.

[Nisheeth Ranjan]

I have this fixed and will check it in tonight protected by a pref that is
disabled by default. I'm not enabling the pref by default because I did not see
much difference in perceived performance on my windows box. Mike and I will test
this on the Mac on (slow machine, slow network), (slow machine, fast network),
(fast machine, slow network), (fast machine, fast network) configurations. If
this makes a significant difference in any configuration, we can enable the pref
by default. Right now, the only data point we have is that this fix does not do
much on a fast machine, fast network configuration on Windows.

Nisheeth
--

[Steve Clark]

This sounds like exactly the right approach. Well done.

[Nisheeth Ranjan]

You can turn on async reflow during doc load by setting the
"layout.reflow.async.duringDocLoad" pref to true. You can control the
timeslice for reflow (the maximum amount of time spent processing reflow
commands synchronously before posting a reflow event and returning to the
event loop) by setting the number of milliseconds in the
"layout.reflow.timeslice" pref.

Lets test what happens with the timeslice set at 1 second, 2 seconds, and 3
seconds. So the values would be 1000000, 2000000, 3000000, respectively.

Nisheeth
--
Simon Fraser wrote:

> In article <39BD7DD5...@netscape.com>, nish...@netscape.com

> (Nisheeth Ranjan) wrote:
>
> > I have this fixed and will check it in tonight protected by a pref
> > that is disabled by default. I'm not enabling the pref by default
> > because I did not see much difference in perceived performance on my
> > windows box. Mike and I will test this on the Mac on (slow machine,
> > slow network), (slow machine, fast network), (fast machine, slow
> > network), (fast machine, fast network) configurations. If this makes
> > a significant difference in any configuration, we can enable the pref
> > by default. Right now, the only data point we have is that this fix
> > does not do much on a fast machine, fast network configuration on
> > Windows.
>

> I see two prefs:
>
> "layout.reflow.timeslice"
> "layout.reflow.async.duringDocLoad"
>
> What values should I be playing with here?
>
> I also note that other layout prefs are "nglayout.foo". Perhaps
> we need some pref renaming here.
>
> Simon
>
> --
> Simon Fraser Entomologist
> sfr...@netscape.com http://people.netscape.com/sfraser/

[Judson Valeski]

Nisheeth Ranjan wrote:

> I have this fixed and will check it in tonight protected by a pref that is
> disabled by default. I'm not enabling the pref by default because I did not see
> much difference in perceived performance on my windows box.

I think this is a *must* have. You may not be seeing much perceived improvement
because you're using a high bandwidth connection. If you're over a modem you have to
wait until the entire page (and it's contents) are downloaded until we display
anything.

Jud

[Nisheeth Ranjan]

Yes, you are right. Mea culpa! :-)

Nisheeth
--
Brendan Eich wrote:

> Nisheeth Ranjan wrote:
>
>> You can turn on async reflow during doc load by setting the
>> "layout.reflow.async.duringDocLoad" pref to true. You can control
>> the
>> timeslice for reflow (the maximum amount of time spent processing
>> reflow
>> commands synchronously before posting a reflow event and returning
>> to the
>> event loop) by setting the number of milliseconds in the
>> "layout.reflow.timeslice" pref.
>>
>> Lets test what happens with the timeslice set at 1 second, 2
>> seconds, and 3
>> seconds. So the values would be 1000000, 2000000, 3000000,
>> respectively.
>

> Microseconds, then -- right?
>
> /be

[Mike Pinkerton]

Nisheeth Ranjan wrote:
>
> Yes, you are right. Mea culpa! :-)

Preliminary findings are that these async reflow changes rock on MacOS.
Loading CNN or the CNN Entertainment page, which lock up my G3/500
powerbook for 4-5 seconds with async off, don't lock it up for anything
greater than the refresh time. Setting the refresh pref to 1 second (a
million ticks) means that my mac's menubar clock never freezes -- I see
every second tick by!

This is with a fast machine and a fast net connection. I'm testing a
slow machine/fast network connection now, and tonight when I go home,
I'll test fast machine/slow net connection.

I would test other parts of the app (mail) for problems with async
reflow (hyatt is very worried about trees and async) but mail keeps
disappearing from my builds so I can't get to it.

[David Hyatt]

If it makes that much of a difference, then we should do it. It is likely
that trees will experience obscure regressions from turning this on
however. I don't mind this, but we should be prepared for it...

dave

[Nisheeth Ranjan]

Hey Dave,

Do you remember what kind of user interaction caused tree viewer regressions?
I'd like to check if the regressions still happen. If you have some spare
cycles to test this out on Windows, that would be great too.

Thanks!

Nisheeth
--
David Hyatt wrote: