324883 - Scrolling is slow/laggy and causes high CPU load

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Dennis Jacobfeuerborn]

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

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this every scrollable page, or just some pages?

Comment 2

[Dennis Jacobfeuerborn]

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

[Adam Guthrie]

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.

Comment 4

[Chris Blore]

This looks as though it is a dupe of bug 324819

Comment 5

[Andrew Schultz]

Attachment: testcase

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

Comment 6

[Dennis Jacobfeuerborn]

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

Comment 7

[Dennis Jacobfeuerborn]

Attachment: 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

[Philip Langdale]

It's every scrollable page for me.

Comment 9

[Hiro]

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+)

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[William L. Hartzell]

We are seeing this on OS/2 also.

Comment 12

[Julien "_FrnchFrgg_" RIVAUD]

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

[Sergei Dolgov]

confirming for BeOS builds.
Looks like every page scrolls slower now

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It makes it more readable to me.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 18

[Dennis Jacobfeuerborn]

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

Comment 19

[Felix Miata]

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.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Works for me, and if it is a regression, it's not likely to be this patch.

Comment 21

[Felix Miata]

Oops. Problem in comment 19 is at least two days old.