Last Comment Bug 282750 - Extremely slow scrolling of ESPN.com with trunk builds
: Extremely slow scrolling of ESPN.com with trunk builds
Status: RESOLVED FIXED
: fixed1.8, regression, testcase, top100
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
http://www.espn.com/
Depends on:
Blocks: 309224
  Show dependency treegraph
 
Reported: 2005-02-18 12:22 PST by Ryan VanderMeulen [:RyanVM]
Modified: 2006-03-12 18:18 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (3.54 KB, text/html)
2005-10-01 07:47 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
Better testcase (3.86 KB, text/html)
2005-10-03 03:37 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
fix (2.09 KB, patch)
2005-10-05 22:20 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
bzbarsky: review+
bzbarsky: superreview+
asa: approval1.8rc1+
Details | Diff | Splinter Review

Description Ryan VanderMeulen [:RyanVM] 2005-02-18 12:22:26 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050218 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050218 Firefox/1.0+

I've noticed since I started to play around with the trunk (after previously
using the 1.0 release build) that espn.com performance is greatly diminished in
comparison to the Aviary branch.  Scrolling is very slow and eats up my CPU (an
AMD Barton @ 2.26GHz), slowing down everything else on my system too.

Reproducible: Always

Steps to Reproduce:
Comment 1 Steve England [:stevee] 2005-04-08 17:43:04 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050408
Firefox/1.0+
http://www.espn.com/ is scrolling fine for me. Are you still seeing this problem
with later trunk builds?
Comment 2 Ryan VanderMeulen [:RyanVM] 2005-04-08 17:46:06 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050408
Firefox/1.0+

Yup, still seeing it.
Comment 3 facted 2005-04-10 13:23:30 PDT
I am seeing this bug as well with april 8th trunk build.
Comment 4 facted 2005-04-11 05:35:38 PDT
This seems to be related to ClearType (turn it off and the page scrolls fine).
This is also the case for bug #  201307 which seems to be very similar.
Comment 5 Caleb 2005-04-11 13:33:08 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050411
Firefox/1.0+

Not using ClearType and scrolling is HORRIBLY slow.
Comment 6 Ryan VanderMeulen [:RyanVM] 2005-06-29 18:12:24 PDT
I narrowed the regression window down. This horrible slowdown first appeared
with the 2004-09-04 nightly.  Looking at Bonsai for that time frame, it seems
that the likely culprit is the patch checked in for Bug 72747, which made many
changes related to scrolling.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-03&maxdate=2004-09-04&cvsroot=%2Fcvsroot

Adding dbaron and roc as CCs to this bug.
Comment 7 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2005-06-29 18:21:08 PDT
You didn't mention build hours of the nightlies, but they're generally not
generated at midnight. 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-03&maxdate=2004-09-05&cvsroot=%2Fcvsroot
is a broader range of checkins to consider, but hours (for both the build
without the problem and the build with) would be nice.
Comment 8 Ryan VanderMeulen [:RyanVM] 2005-06-29 18:35:18 PDT
The timestamp for the working Sept. 3 build is: 03-Sep-2004 08:45
The timestamp for the broken Sept. 4 build is: 04-Sep-2004 08:25

This is the query from Sept. 3 8PM to Sept. 4 8:30PM
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-03+20%3A00%3A00&maxdate=2004-09-04+20%3A30%3A00&cvsroot=%2Fcvsroot
Comment 9 Zach Lipton [:zach] 2005-08-23 22:51:25 PDT
This is a pretty major issue. See
http://testrunner.mozilla.org/litmus/show_test.cgi?id=260. 
Comment 10 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-10-01 07:47:00 PDT
Created attachment 198133 [details]
testcase

The overflow-y/overflow-x patch exposed this bug, because there is a rule for
div class="navdivider" with overflow-y:hidden.
This testcase is comparable to the espn.com situation, regarding the scrolling
regression.
It scrolls fast for me in Mozilla1.7.12, but slow in current trunk build.
The precise regression range I get is between 2004-08-10 and 2004-08-11:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-10+07%3A00%3A00&maxdate=2004-08-11+08%3A00%3A00&cvsroot=%2Fcvsroot

Maybe because of bug 253572?
Comment 11 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-10-01 09:44:00 PDT
Ok, I backed out the patch from bug 253001, and that seems to fix the slow
scrolling issue on this testcase.
I think this is rather important to fix for 1.8.
Comment 12 Boris Zbarsky [:bz] 2005-10-02 13:26:42 PDT
Martijn, can you try experimenting with the MAX_OPAQUE_REGION_COMPLEXITY value?
 What do you see?

I really don't see how that should be affecting things here, though.  :(
Comment 13 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-10-02 14:55:06 PDT
Setting MAX_OPAQUE_REGION_COMPLEXITY to 1 still scrolls slowly.
Setting MAX_OPAQUE_REGION_COMPLEXITY to 100 scrolls fast.
Comment 14 Boris Zbarsky [:bz] 2005-10-02 22:14:36 PDT
Is the breakpoint the same as the number of divs you have on the page or
thereabouts?

Note that I'm _really_ confused because I'm not really seeing much in the way of
opaque views here...
Comment 15 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-10-03 03:13:32 PDT
There are 92 <div class="navdivider">'s in the testcase.
I've tested with the following MAX_OPAQUE_REGION_COMPLEXITY values:
50 fast
47 fast
45 reasonably fast although it's a bit slower
40 slow
30 slow
Comment 16 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-10-03 03:37:25 PDT
Created attachment 198291 [details]
Better testcase

This quantifies the slower scrolling a bit.
The results I get are:
2004-08-10 build: 2604ms
2004-08-11 build: 10344ms
2005-10-02 build: 10536ms
I'm using a Duron600Mhz, 512MB, NVidia GeForce2MX 200/100 on WinXP.
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-05 21:37:21 PDT
The navdividers are opaque and have views.

This is happening in nsViewManager::CanScrollWithBitBlt. It creates a display
list to see if there's anything that prevents us from doing a bitblt.
OptimizeDisplayList fills up the region with MAX_OPAQUE_REGION_COMPLEXITY
different rectangles and then gets to the scrolled view. This view has a uniform
background and so we would normally add its area to the opaque region, which
covers up the views underneath so we know that none of that underneath content
(which is not being scrolled) is visible. In this case we don't add the scrolled
view's area to the opaque region because we've already maxed out the complexity.
This means we think the element is transparent with the underneath content
showing through, and therefore we have to do a full repaint instead of just a
bitblt.
Comment 18 Boris Zbarsky [:bz] 2005-10-05 21:45:32 PDT
Hmm.  So could we ignore the MAX_OPAQUE_REGION_COMPLEXITY setting for opaque
background views when doing scrolling analysis?  That is, are there cases when
we'd have lots of non-opaque views with uniform background?
Comment 19 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-05 22:03:56 PDT
Sorry, my last comment was incorrect.
Comment 20 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-05 22:11:18 PDT
Well, it's correct enough. In this case the uniform-background path doesn't kick
in, but the canvas background is opaque and it should be hiding the views
underneath it, but it isn't added to the opaque region because of the complexity
limit.
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-05 22:20:12 PDT
Created attachment 198666 [details] [diff] [review]
fix

I don't like the idea of allowing unlimited complexity during scroll analysis,
because it could cause N^2 behaviour in exactly the situations where we
originally introduced the complexity limit (lots of abs-pos elements with solid
backgrounds).

This approach lets us violate the complexity limit if the area to be added to
the opaque region will entirely cover the opaque region. This is safe because
it will actually make the opaque region very simple. It means that solid canvas
backgrounds, as in this case, will always be able to be added.
Comment 22 Boris Zbarsky [:bz] 2005-10-05 22:27:04 PDT
Comment on attachment 198666 [details] [diff] [review]
fix

Nice!  r+sr=bzbarsky
Comment 23 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-06 10:48:31 PDT
checked in on trunk.
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-06 10:49:50 PDT
Let's apply for RC1 approval in a couple of days.
Comment 25 Ryan VanderMeulen [:RyanVM] 2005-10-06 16:06:20 PDT
This fix dropped the rendering time of the testcase from 2110ms to 1891ms on my
(extremely fast) Athlon64 X2 3800+ system. I'm sure it'll make a bigger
difference on slower systems, but there's certainly a positive impact on
performance!
Comment 26 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-06 18:20:43 PDT
Comment on attachment 198666 [details] [diff] [review]
fix

This is a low-risk fix that should go on the branch. It fixes scrolling
performance on espn.com and probably some other sites.
Comment 27 Asa Dotzler [:asa] 2005-10-10 14:31:32 PDT
This bug says in the summary that it's a problem on the trunk. I don't see any
obvious slowness on the branch at ESPN. Do we need this fix there? What's the
risk and what kind of testing would we need to feel confident about taking this
change into 1.8rc1?
Comment 28 Boris Zbarsky [:bz] 2005-10-10 14:41:53 PDT
> This bug says in the summary that it's a problem on the trunk.

Trunk as of February 2005....

> Do we need this fix there?

I would say yes.

> What's the risk and what kind of testing would we need to feel confident about
> taking this change into 1.8rc1?

The risk is very very low.  I can't actually think of any cases in which the new
code would behave differently from the old one painting-wise except to be a bit
faster, so I'm really not even sure what to suggest we test....  Scrolling in
general, I guess.  Especially on pages with various opacity, positioned content,
etc.
Comment 29 Asa Dotzler [:asa] 2005-10-10 15:44:03 PDT
Comment on attachment 198666 [details] [diff] [review]
fix

I don't think this is a big enough performance problem to warrant a change this
late in the game.
Comment 30 Asa Dotzler [:asa] 2005-10-10 16:55:58 PDT
Comment on attachment 198666 [details] [diff] [review]
fix

After email discussion with Boris, we've agreed to take this fix. Thanks for
the follow-up BZ.
Comment 31 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-10 19:33:04 PDT
Fixed on branch.

Note You need to log in before you can comment on or make changes to this bug.