Closed Bug 442291 Opened 12 years ago Closed 12 years ago

Very slow scrolling


(Core :: Graphics, defect)

Not set





(Reporter: tiagomatos, Assigned: roc)




(Keywords: regression, testcase)


(9 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061712 Fedora/3.0-1.fc9 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061712 Fedora/3.0-1.fc9 Firefox/3.0

The url mentioned is very slow to scroll on my system. Relevant details:

- Dell Latitude D630 laptop with an NVIDIA GPU Quadro NVS 135M (G86GL)
- Fedora 9 OS x86_64 with currently available updates intalled
 - kernel-
 - xorg-x11-server-Xorg-
 - compiz-0.7.6-2.fc9.x86_64 (i.e. running under a compositing manager)
- nvidia's driver version 177.13

With NV_CTRL_INITIAL_PIXMAP_PLACEMENT_SYSMEM (the driver default) set it is slow.

With NV_CTRL_INITIAL_PIXMAP_PLACEMENT_VIDMEM (the future driver default according to [1]) is *REALLY SLOW*.


Reproducible: Always
Blocks: 90198
Also, it doesn't matter if I enable or disable smooth scrolling.
for me it is slow too.

nvidia 6200 with stock nv driver (nvidia's driver doesn't work in opensuse 11.0 atm) with xcompmgr (a compositing manager).
Michael, can you test this?

A reduced testcase would be very helpful.
The graphic at the bottom is causing this. When that is not displayed scrolling is as fast as it ever was on my computer. I don't know how they're making that effect but it looks like a fixed background which is known to be slow.
A reduced testcase would still be useful, to get noise out of the profiling we're going to have to do.
Attached file testcase
With a branch build, I get 5203ms as result.
With current trunk build, I get 14084ms as result.
Component: General → GFX: Thebes
Ever confirmed: true
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
I get 20935ms on the environment from comment #0.
Attached file sysprof profile
Adding a sysprof profile which I ran while executing the testcase.

Unfortunately and unsurprisingly it shows that most of the time is spent inside nvidia's proprietary driver.
Thanks Rui. I guess I'd need to start up my Linux VM to read that profile. Who wants to dig deeper into this?
I don't think the testcase attached here exercises the same codepaths that the URL provided does. On this testcase I get faster scrolling with the driver's InitialPixmapPlacement=2 option while on the URL it's a lot slower with that option.

Btw, I've disabled flash on the URL for all of my testings.

I've done 2 more profiles now at the URL and with more debuging symbols installed (namely for the X server and pixman). These profiles were taken while just scrolling at URL and they differ only on the IPP driver option being 1 (default, slow) or 2 (a lot slower). Find them at
On Mac, on Martijn's testcase I get
Trunk: 8713ms
1.8.1: 6575ms

So a small regression but not nearly as severe as what Martijn reported on Linux.
In my Linux VM:
Trunk: 13773ms
1.8.1: 8281ms
(In reply to comment #13)
> So a small regression but not nearly as severe as what Martijn reported on
> Linux.

Correction, I was reporting this on Windows (I should have added that).
OK, some more experiments. Mac and Linux window sizes differ, so we can't compare results across platforms.

Mac                  Linux
Trunk: 10430ms       13643ms
1.8.1: 7789ms        7011ms

Modifying the testcase to just change the background color (forces repainting the window) instead of scrolling:
Mac                  Linux
Trunk: 6610ms        10003ms
1.8.1: 7741ms        7185ms

So the interesting thing is that on both platforms, in 1.8.1 painting and scrolling are basically the same time (scrolling a little slower in each case). This makes sense.

On trunk, the scrolling version of the test is a lot slower than just doing a repaint, on both platforms. I will try to figure out why.

It's interesting to see that painting sped up on trunk on Mac, probably due to the shift to Quartz, but slowed down on Linux, for unknown reasons. Someone should look into the latter at some point.
Attached file Paint-only testcase
The paint-only version of Martijn's testcase, for reference.
The difference in performance between scrolling and just painting seems be entirely due to frame dropping: at each scroll, we synchronously paint, so we paint every single scroll step. When we're just painting, the paints are asynchronous, and multiple paints are coalesced if we didn't have time to paint between steps. In one test I ran in a Mac debug build, we painted 193 times for the scrolling test and only 153 times for the painting test.
This fixes this testcase for me on Mac --- at least, it makes scrolling as fast as just painting, by causing it to drop frames in the same way.

There are really two changes:
-- When we bitblit, we do a Composite() in UpdateViewAfterScroll, so that's forcing us to paint the whole window once per scroll operation. We don't want to bitblit and then not Composite(), because that will create a longer interval when we've half-updated the screen. So, avoid bitblitting by returning false for CanBitBlit if we're going to have to repaint more than half the window.
-- Unfortunately that didn't fix the problem. Turns out that the repainting test still wins because of the extra paint delay we get from VM_REFRESH_DEFERRED (which spawns an XPCOM InvalidateEvent, which does the actual native invalidate). So, make the non-bitblit scrolling path use VM_REFRESH_DEFERRED as well. This makes the scrolling test behave just like the repainting test. The scrolling test is still marginally slower for me (7000ms vs 6700ms), but that's probably just overhead from display list analysis etc.
Assignee: nobody → roc
Attachment #336979 - Flags: superreview?(bzbarsky)
Attachment #336979 - Flags: review?(bzbarsky)
Comment on attachment 336979 [details] [diff] [review]
fix (Mac at least)

OK, let's try it.
Attachment #336979 - Flags: superreview?(bzbarsky)
Attachment #336979 - Flags: superreview+
Attachment #336979 - Flags: review?(bzbarsky)
Attachment #336979 - Flags: review+
Pushed 5b69c1cd5976.
Closed: 12 years ago
Resolution: --- → FIXED
The bug was originally about Linux but AFAICT the patch doesn't seem to affect the path taken by Linux; are you sure this bug should be marked fixed?
The changes to nsScrollPortView.cpp should affect Linux.

Testcase still shows big difference between FF2 and FF3

6987  - FF2
12197 - FF3
One thing that'd be useful is to run this testcase. Test both painting and scrolling. If painting is roughly the same speed as scrolling, then this patch "worked", and the remaining issue is probably paint performance.
11938 - scrolling
7412  - painting
42855 - scrolling
22165 - painting

firefox 3.0.1 @ openSUSE 11.0, GNOME, Compiz, without AWN (only GNOME's panel - it really makes difference)
Jakub, I'm only interested in a builds containing this patch, i.e. NOT 3.0.1.

Romaxa: hmmmmm. Are you sure you got this patch?

The next debugging step is to start up a debug build, set gDumpPaintList=1 in the debugger (or just by hacking sources, I suppose), and then count the numer of paint operations logged between the START and END messages for each of scrolling and painting. This patch should ensure they're roughly the same.
Something has got to be wrong here:

FF 3.0.1 - 15574
FF 3.1 with patch - 32888

Haven't tried painting. Did the scroll test twice and got similar results.
Reverting the patch didn't help, so something else regressed this. Maybe a Cairo change caused this to take a path that is not accelerated by the nvidia driver? I'm using the latest driver and I know that had some additional Xrender acceleration support.
Try the paint test. All you have to do is click the other button. If that test has regressed, then it's definitely a cairo/X issue.
I have check it on N810 (latest trunk + fixed X server/cairo perf problems)...

Visually scrolling very responsive and scroll fast...
but timer results shows:
scrolling: 20531
painting : 12831
romaxa, please try the steps in comment #28.
Ok, in next comment I will attach gDumpPaintList results... but before I found interesting results with Qt port:

I was testing on Desktop PC, Full screen 24"

gtk-scroll: 14845
gtk-paint : 7621

qt-scroll : 4292
qt-paint  : 4157

1) even for paint Gtk/Xrender port 2-x slower than Qt
2) diff between Gtk scroll/paint ~2x, Qt - almost the same.
That is indeed very interesting!
On device Qt port also very fast:
N810-qt-paint : 7685
N810-qt-scroll: 10838

N810-gtk-paint:  12610
N810-gtk-scroll: 18776
1) Windows XP and 2003
2) Minefield: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre ID:20080910043000

All testcases are painfully slow!

Using the test on Ubuntu Linux, 64bit, Intel Q6600 CPU, all tests fullscreen on 1600x1200 screen, GeForce 8400 GS

Name                 Build                        Scrolltest Painttest
FF 3.0.1 32bit Linux Gecko/2008070206 Firefox/3.0.1 39211ms 20898ms
Seamonkey 1.1.11 32bit Linux Gecko/20080702 SeaMonkey/1.1.11 15438ms 15055ms
FF nightly Linux 64bit Gecko/20080910020329 Minefield/3.1b1pre 36222ms 22334ms
FF nightly Linux 32bit Gecko/20080910020324 Minefield/3.1b1pre 39278ms 19517ms
FF nightly Windows on Wine 1.1.4 32bit Gecko/20080910043000 Minefield/3.1b1pre 122245ms 56513ms
FF 3.0.1 Windows on Wine 1.1.4 32bit Gecko/2008070208 Firefox/3.0.1 133886ms 52331ms
Chrome on Wine 1.1.2 Tests don't run
Konqueror 3.5.9 (Ubuntu build, 64bit) Linux Tests don't run

Summary: Seamonkey stable is by far the fastest, the FF nightlies and FF stable don't differ much, 64 bit versus 32 bit doesn't seem to have a big influence.
SeaMonkey stable uses Gecko 1.8.x like Firefox 2.x ;) .
WINE numbers are useless. Comment #37 is also useless. Please don't spam my bug with useless info.

romaxa, can you please give me the info from comment #28.
Attached file Paint log
Attached file Scroll log
Ok, seems on our maemo Xomap problem was fixed:
scroll: 18577
panint: 11770

After fixing Xomap:
scroll: 7695
panint: 7197
Depends on: 454959
You need to log in before you can comment on or make changes to this bug.