675866 - Meta: scrolling complex pages like Engadget is consistently slower and jerkier than the competition

Reporter

Description

•

13 years ago

If you visit http://www.engadget.com in Firefox (release or nightly) and hold the down arrow after the page has completely loaded and compare the time it takes the page to scroll to the bottom against IE9, Chrome, or Opera, you'll find that it's not only about 50-100% slower overall, but it's also got more stutter and jerkiness than the others. I get smoothest and fastest results from Opera 12, then IE9, then Chrome. Firefox is a distant 4th in speed. Steps to reproduce: 1. visit http://www.endgadget.com in Firefox, Opera, IE9, and Chrome 2. wait for page to fully load. 3. depress and hold the down arrow key on your keyboard. 4. time the scroll to the bottom of the page. 5. additionally observe the smoothness of the scroll. Results: On my system, Firefox takes approximately 21 seconds to scroll to the bottom of the page. Opera takes about 11 seconds. IE9 takes about 12 seconds. Chrome takes about 12 seconds. Also, all other browsers scroll more smoothly and more evenly down the page. Opera's scrolling is the smoothest and most even. My graphics setup is this: Adapter Description: Intel(R) HD Graphics Family Vendor ID: 8086 Device ID: 0126 Adapter RAM: Unknown Adapter Drivers: igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32 Driver Version: 8.15.10.2321 Driver Date: 3-6-2011 Direct2D Enabled: true DirectWrite Enabled: true (6.1.7601.17563) WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686) GPU Accelerated Windows: 1/1 Direct3D 10

Asa Dotzler [:asa]

Reporter

Comment 1

•

13 years ago

Oops, left off that this is on a stock Windows 7 64-bit Professional install running on a Core i5-2520M CPU at 2.5 GHz with 4 GB RAM.

Timothy Nikkel (:tnikkel)

Comment 2

•

13 years ago

So there are at least two issues here: the actual performance of scrolling including any negative effects like jerkiness, and the amount that the arrow keys actually scroll the page (whether it be for a single press or held for a duration). In the past we've noticed that we scroll fewer pixels for each key press than other browsers, so it's probably a no-brainer to look into how much we should increase this amount by.

Timothy Nikkel (:tnikkel)

Comment 3

•

13 years ago

Asa, would you mind trying this try build http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-37b1f915e389/ and seeing if anything is different for you?

Asa Dotzler [:asa]

Reporter

Comment 4

•

13 years ago

It doesn't feel different to me. It still feels just as slow to scroll long pages like endgadget.

nasko_naskov

Comment 5

•

13 years ago

Hi.Scrolling is very bad on this page: http://www.notebookcheck.net/Computer-Games-on-Laptop-Graphic-Cards.13849.0.html .Using chromium and same page the scrolling is very smooth.

nasko_naskov

Comment 6

•

13 years ago

Scrolling by dragging the vertical scroll bar is smooth,but scrolling with arrows and mouse scroll is very lagy and choppy

Alex Faaborg [:faaborg] (Firefox UX)

Comment 7

•

13 years ago

>Scrolling by dragging the vertical scroll bar is smooth,but scrolling with arrows and mouse >scroll is very lagy and choppy yeah at the risk of this turning into more of a discussion than a bug, can anyone explain why that is the case? My impression is that we are just repainting for each discreet event with the arrow keys at a 3 line interval. Why would we not perform pixel scrolling with an acceleration model for keyboard input?

Alex

Comment 8

•

13 years ago

Should Bug 595400 be marked as a duplicate of this one?

Timothy Nikkel (:tnikkel)

Comment 9

•

13 years ago

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #7) > >Scrolling by dragging the vertical scroll bar is smooth,but scrolling with arrows and mouse >scroll is very lagy and choppy > > yeah at the risk of this turning into more of a discussion than a bug, can > anyone explain why that is the case? For that specific page the reason is that scrolling is slow when the mouse is over the page content, but fine (at least for me) when the mouse is not over page content. (Part of) the problem is that we send a synthetic mouse move after a scroll so that any hover styles and the cursor are updated correctly (ie if the mouse is over a link after scrolling). The synthetic mouse move may cause us to do reflows or other work on every scroll operation. (It seems like this might be hurting us more than it should though.) Whereas Chrome doesn't update the cursor or hover styles on scrolling.

Timothy Nikkel (:tnikkel)

Comment 10

•

13 years ago

Asa, would you like to try this build http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-02fd2e36d868/ ?

Asa Dotzler [:asa]

Reporter

Comment 11

•

13 years ago

(In reply to Timothy Nikkel (:tn) from comment #10) > Asa, would you like to try this build > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com- > 02fd2e36d868/ ? tn, I'll take a look at this tomorrow if I can find a free minute. Sorry for the delay.

Timothy Nikkel (:tnikkel)

Comment 12

•

13 years ago

I hope you're not used to the new doubled scrolling speed as this try server build is orthogonal to that and I want an apples to apples comparison. :)

Asa Dotzler [:asa]

Reporter

Comment 13

•

13 years ago

(In reply to Timothy Nikkel (:tn) from comment #12) > I hope you're not used to the new doubled scrolling speed as this try server > build is orthogonal to that and I want an apples to apples comparison. :) I'm very conscious of that. I'm actually avoiding getting used to the new doubling just so I can test this out properly. I'm motivated :-)