Closed
Bug 675866
Opened 13 years ago
Closed 2 years ago
Meta: scrolling complex pages like Engadget is consistently slower and jerkier than the competition
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: asa, Unassigned)
References
(Depends on 1 open bug)
Details
(Whiteboard: [Snappy:P2])
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
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.
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.
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?
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.
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.
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
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?
Should Bug 595400 be marked as a duplicate of this one?
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.
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/ ?
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.
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. :)
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 :-)
Comment 14•13 years ago
|
||
You can see the slow scroll over links effect on this page too: http://android.modaco.com/forum/453-zte-blade-libra-blademodacocom/
Updated•13 years ago
|
Whiteboard: [Snappy]
Comment 15•13 years ago
|
||
We will track scrolling improvements with this bug
Summary: scrolling complex pages like Engadget is consistently slower and jerkier than the competition → Meta: scrolling complex pages like Engadget is consistently slower and jerkier than the competition
Whiteboard: [Snappy] → [Snappy:P1]
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
Should bug 198964 block this?
Comment 20•13 years ago
|
||
Jared to decided to use bug 198964 for smooth scrolling
Whiteboard: [Snappy:P1] → [Snappy:P2]
Comment 21•13 years ago
|
||
There are some bugs blocking this that should block also bug 198964 then. Like bug 206438 or bug 702463.
Comment 23•13 years ago
|
||
We have two (or more) meta bugs to track scrolling performance issues, maybe we should join them.
Updated•2 years ago
|
Severity: normal → S3
Comment 25•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 12 votes.
:dholbert, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(dholbert)
Comment 26•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(dholbert)
Comment 27•2 years ago
|
||
Inactive metabug
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•