Scrolling is slow/laggy and causes high CPU load

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
12 years ago
4 years ago

People

(Reporter: Dennis Jacobfeuerborn, Assigned: roc)

Tracking

({perf, testcase})

Trunk
x86
Linux
perf, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1

After the landing of the patch for bug 317375 it seems rendering causes significantly more CPU load than in the builds before. This becomes most apparent when scrolling a page. In pre-317375 builds scrolling is instantaneous on most pages while in the latest build there is a noticable lag. A quick check using 'top' showed that in older builds scrolling makes Firefox use about 10-20% of the CPU where the current build uses 70-80%.

Reproducible: Always

Steps to Reproduce:




Some information about my system:
Fedora Core Test 2
AthlonXP 1600+
Radeon 9500pro (r300 based) using the XOrg 'radeon' driver
(Reporter)

Updated

12 years ago
Blocks: 317375
Version: unspecified → Trunk
Is this every scrollable page, or just some pages?
(Reporter)

Comment 2

12 years ago
Every scrollable page shows this but on some pages the effect is more noticable than on others. On http://www.squarefree.com/burningedge/ the effect is mild but noticable whereas on http://www.kahvi.org/news.php the scrolling becomes really sluggish.
In both cases when I go to the middle of the page and then move the mousewheel up and down pretty quickly for about five seconds and then let go of the mouse the page keeps scrolling up and down while Firefox seems to work off the queue of events.
In earlier builds the scrolling is instantaneous on both pages and I cannot reproduce even the slightest bit of lag.

Comment 3

12 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1

I'm seeing this, too. Added the URL of a page where it's very noticeable.
Assignee: nobody → roc
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → ian
Summary: scrolling/rendering causes high CPU load → Scrolling is slow/laggy and causes high CPU load

Comment 4

12 years ago
This looks as though it is a dupe of bug 324819

Comment 5

12 years ago
Created attachment 209806 [details]
testcase

While scrolling this page, X uses 2-3x more CPU with trunk build 2006012603 (and is jerkier) compared to 2006012504,

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf, testcase
(Reporter)

Comment 6

12 years ago
(In reply to comment #4)
> This looks as though it is a dupe of bug 324819

http://www.kahvi.org/news.php does not contain fixed positioned elements so I don't think this is the same problem.
The scrolling performance on the kahvi page raises significantly though when you remove the background attribute from the body tag and from the table cell that contains the long release list but it still doesn't get as snappy as with older builds.
(Reporter)

Comment 7

12 years ago
Created attachment 209840 [details]
client-resized image grid testcase

To use this testcase you need to put 18 fullscreen jpeg images named 1.jpg to 18.jpg in the same folder as the html file.

This test creates an incredible lag, *much* more pronounced than the pages I mentioned above. In the older builds there is no lag at all.
Now when I remove the width and height attributes from the image tags speed improves dramatically and is much more in line with the faster pages mentioned above.

Since the client side resizing has such an huge impact could this be related to bug 304561 ? (Which among other things says "I understand that the resized-image-caching thing is a core issue rather than a Firefox problem per se, as it also affects scrolling on pages that dynamically resize images.")

Comment 8

12 years ago
It's every scrollable page for me.

Comment 9

12 years ago
After bug317375 does FIXED, the scroll speed of Camino and Firefox is heavy. 

Mac OS X 10.3.9
trunk Firefox
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060127 Firefox/1.6a1
trunk Camino 2006012621 (v1.0+)
It's probably the CanScrollWithBitBlt analysis going wrong somewhere, maybe I regressed it during development of the patch. I will look into this in a few days.

Comment 11

12 years ago
We are seeing this on OS/2 also.
Whereas I do see more sluggish scrolling (and saw it before, when I manually applied the patch, but thought that was due to the debug build), the attachment does not exhibit such behaviour for me on Linux.

Comment 13

12 years ago
confirming for BeOS builds.
Looks like every page scrolls slower now
Created attachment 210814 [details] [diff] [review]
fix

The second part of the patch, to nsScrollPortView.cpp, fixes the really serious uninitialized variable bug which I think is causing the problems for most people.

The first part of the patch adds some useful debugging code and fixes a bug where I meant to be using IsUniform (as indicated by the original comments) and was simply calling the wrong function. This fixes some more complicated situations where we used to bitblit and suddenly, regressively, aren't.
Attachment #210814 - Flags: superreview?(dbaron)
Attachment #210814 - Flags: review?(dbaron)
Comment on attachment 210814 [details] [diff] [review]
fix

>-          if (!(r.Contains(aRect) && r.Contains(aRect + aDelta) &&
>-                item->IsVaryingRelativeToFrame(aBuilder, aBuilder->GetRootMovingFrame()))) {
>+          PRBool skip = r.Contains(aRect) && r.Contains(aRect + aDelta) &&
>+              item->IsUniform(aBuilder);
>+          if (!skip) {

Adding a variable (skip) doesn't seem to add much here; feel free to remove if you agree.

r+sr=dbaron
Attachment #210814 - Flags: superreview?(dbaron)
Attachment #210814 - Flags: superreview+
Attachment #210814 - Flags: review?(dbaron)
Attachment #210814 - Flags: review+
It makes it more readable to me.
checked in
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

12 years ago
Scrolling speed is indeed back to normal for me. Thanks!

Comment 19

12 years ago
As of today's trunk on Linux HOME and END keys no longer do anything when focus is in a web page, and arrow keys no longer produce expected scroll behavior either. I have FAYT disabled.
Works for me, and if it is a regression, it's not likely to be this patch.

Comment 21

12 years ago
Oops. Problem in comment 19 is at least two days old.
You need to log in before you can comment on or make changes to this bug.