442291 - Very slow scrolling

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Rui Matos]

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-2.6.25.6-55.fc9.x86_64
 - xorg-x11-server-Xorg-1.4.99.902-3.20080612.fc9.x86_64
 - 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*.

[1] http://www.nvnews.net/vbulletin/showpost.php?p=1690867&postcount=19


Reproducible: Always

Comment 1

[Rui Matos]

Also, it doesn't matter if I enable or disable smooth scrolling.

Comment 2

[u294409]

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

Comment 3

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

Michael, can you test this?

A reduced testcase would be very helpful.

Comment 4

[Michael Ventnor]

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.

Comment 5

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

A reduced testcase would still be useful, to get noise out of the profiling we're going to have to do.

Comment 6

[Martijn Wargers (dead)]

Attachment: background-image 1

Comment 7

[Martijn Wargers (dead)]

Attachment: background-image 2

Comment 8

[Martijn Wargers (dead)]

Attachment: testcase

With a branch build, I get 5203ms as result.
With current trunk build, I get 14084ms as result.

Comment 9

[Rui Matos]

I get 20935ms on the environment from comment #0.

Comment 10

[Rui Matos]

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

Comment 11

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

Thanks Rui. I guess I'd need to start up my Linux VM to read that profile. Who wants to dig deeper into this?

Comment 12

[Rui Matos]

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

http://hng.av.it.pt/~rmatos/bugzilla.mozilla.org-442291/char-IPP1-sysprof.bz2
http://hng.av.it.pt/~rmatos/bugzilla.mozilla.org-442291/char-IPP2-sysprof.bz2

Comment 13

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

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.

Comment 14

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

In my Linux VM:
Trunk: 13773ms
1.8.1: 8281ms

Comment 15

[Martijn Wargers (dead)]

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

Comment 16

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

OK, some more experiments. Mac and Linux window sizes differ, so we can't compare results across platforms.

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

Comment 17

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

Attachment: Paint-only testcase

The paint-only version of Martijn's testcase, for reference.

Comment 18

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

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.

Comment 19

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

Attachment: fix (Mac at least)

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.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 336979 [details] [diff] [review]
fix (Mac at least)

OK, let's try it.

Comment 21

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

Pushed 5b69c1cd5976.

Comment 22

[Michael Ventnor]

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?

Comment 23

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

The changes to nsScrollPortView.cpp should affect Linux.

Comment 24

[Oleg Romashin (:romaxa)]

https://bugzilla.mozilla.org/attachment.cgi?id=327454

Testcase still shows big difference between FF2 and FF3

6987  - FF2
12197 - FF3

Comment 25

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

Attachment: scroll and paint testcase

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.

Comment 26

[Oleg Romashin (:romaxa)]

11938 - scrolling
7412  - painting

Comment 27

[u294409]

42855 - scrolling
22165 - painting

firefox 3.0.1 @ openSUSE 11.0, GNOME, Compiz, without AWN (only GNOME's panel - it really makes difference)

Comment 28

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

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.

Comment 29

[Michael Ventnor]

Something has got to be wrong here:

Scrolling
FF 3.0.1 - 15574
FF 3.1 with patch - 32888

Haven't tried painting. Did the scroll test twice and got similar results.

Comment 30

[Michael Ventnor]

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.

Comment 31

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

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.

Comment 32

[Oleg Romashin (:romaxa)]

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

Comment 33

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

romaxa, please try the steps in comment #28.

Comment 34

[Oleg Romashin (:romaxa)]

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.

Comment 35

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

That is indeed very interesting!

Comment 36

[Oleg Romashin (:romaxa)]

On device Qt port also very fast:
N810-qt-paint : 7685
N810-qt-scroll: 10838

N810-gtk-paint:  12610
N810-gtk-scroll: 18776

Comment 37

[Bryan]

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!

~B

Comment 38

[Arthur]

Using the https://bugzilla.mozilla.org/attachment.cgi?id=337280 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.

Comment 39

[u294409]

SeaMonkey stable uses Gecko 1.8.x like Firefox 2.x ;) .

Comment 40

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

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.

Comment 41

[Oleg Romashin (:romaxa)]

Attachment: Paint log

Comment 42

[Oleg Romashin (:romaxa)]

Attachment: Scroll log

Comment 43

[Oleg Romashin (:romaxa)]

Ok, seems on our maemo Xomap problem was fixed:
Before:
scroll: 18577
panint: 11770

After fixing Xomap:
scroll: 7695
panint: 7197