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

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.

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.

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?

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

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.

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

>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?

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

(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.

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

(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.

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. :)

(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 :-)

You can see the slow scroll over links effect on this page too: http://android.modaco.com/forum/453-zte-blade-libra-blademodacocom/

We will track scrolling improvements with this bug

There are many bugs about slow scrolling tracked by bug 100951. After a bit of work on scrolling, we should test those bugs to see if they still applies. We should see if bug 206438, about smooth scrolling, is still wanted. And investigate about the solution proposed in bug 702463.

Should bug 198964 block this?

Jared to decided to use bug 198964 for smooth scrolling

There are some bugs blocking this that should block also bug 198964 then. Like bug 206438 or bug 702463.

We have two (or more) meta bugs to track scrolling performance issues, maybe we should join them.