Firefox crashes or hangs on GMail

Scrolling the main GMail window is slow. It should be super fast.

One issue is that the GMail window contains an IFRAME with all the actual content. That IFRAME's viewport scrollframe is not always active, we only activate it on a timer. So when you scroll, it's flipping between active and inactive a lot, which forces repainting of the entire window a lot.

So there's a few things we could do:
1) Increase the scroll activity timeout so we don't flip between active and inactive while scrolling. In selected cases we could make the timeout infinite.
2) Item 1 means we'll be displaying non-subpixel-AA text for longer, so we should fix that for as many cases as possible (including GMail) by detecting when a transparent ThebesLayer has a solid color behind it, and making the ThebesLayer opaque with that background color. That will also speed up drawing and compositing.

Roc I noticed some slow scrolling cases that happen only if you hover a particular area, for instance on http://upload.wikimedia.org/wikipedia/commons/2/2c/USA_New_Jersey_location_map.svg if you mouse over the image it scrolls slowly, but on the white area it scrolls fine. This seems to happen on embed youtube videos as well. Are they related to this bug or is it something else?

I suggest that we block final release on this; GMail's a pretty key site :)

I don't know if bug 581576 is the same issue, if so, please feel free to duplicate and make it block final release.

*** Bug 583038 has been marked as a duplicate of this bug. ***

--> beta6+

me too on pre beta7

please ignore my above comment

Would this bug also cover the slow scrolling on Google Reader?

Roc, what's our plan here going forward? Just want to make sure this doesn't fall off the radar.

Is there any progress going into this bug or atleast has the cause been investigated?

If there had been, I would have commented.

The changes I mentioned in comment #0 were made in other bugs.

I tested scrolling in GMail's conversation view and folder view. During continuous scrolling, at each step we're only painting the scrollbar and the horizontal strip that was scrolled into view. This is good. It's still true even when a chat pane is open --- the chat pane is placed in its own layer, so doesn't cause extra repainting. Everything is working as designed there.

This bookmarklet:
javascript:void((function(){var%20i=0;var%20start=Date.now();function%20f(){if(++i==50){alert((Date.now()-start)+"ms");return;}document.getElementsByTagName('iframe')[4].contentWindow.scrollTo(0,i*5);setTimeout(f,10);}f();})())
is a good way of measuring GMail scrolling performance.

In a big folder view (100 threads of my Bugzilla folder), I get about 2900ms (Linux, megafast PC) without GPU acceleration. That's about 58ms per frame which is definitely not good. (With GL acceleration it's a little slower, which is probably expected on this testcase, since on this machine the X server is perfectly capable of keeping up as it composites everything asynchronously.)

Er, those numbers were for a debug build. For an opt build, it's 2200ms. That's still 44ms per frame, so still room for improvement!

Er, fail again. I was measuring a different version of the bookmarklet that scrolled through a lot more frames. With the bookmarklet above, my opt build takes about 560ms if I run the bookmarklet repeatedly, about 700ms if I wait for five seconds between each invocation (which lets the scroll activity timer expire).

So that's better than 60fps. If GMail scrolling speed is a problem, I'll need a slower machine to see it :-).

I've used the bookmarklet here and gotten 521ms. PC is running Windows 7 Pro x64, GeForce 7950GT, Core i7-920 @ 2.8ghz, 6GB DDR3, etc etc.

That's pretty fast. Does GMail scrolling feel fast to you in practice?

I don't have any scrolling issues with Gmail at this time.

On my nearly-4-year-old Macbook Pro, I get around 1200ms for 50 frames. Not bad, but less than 60fps. I'll dig into this a little more.

76% of the time is under _handleWindowNeedsDisplay --- painting. The rest is system/Appkit overhead plus some event firing (timeout events, scroll events).

Under painting:

16.7% under BuildDisplayListForStackingContext (display list construction)
10% under nsDisplayList::ComputeVisibilityForRoot (computing visible rects for everything)
9.3% under FrameLayerBuilder::BuildContainerLayerFor (layer construction)
2.5% under FrameLayerBuilder::WillEndTransaction (updating FrameLayerBuilder stuff)
31.7% under BasicLayerManager::EndTransaction (compositing layer tree)

Under EndTransaction:
10% painting the scrolled-into-view contents of ThebesLayers
21% drawing ThebesLayerBuffers into the destination. Almost all of that is in CGBlt_copyBytes --- memcpy.

Created attachment 494154
GMail folder view display list

Looking into ComputeVisibilityForRoot, the cost is all about nsDisplayClip::ComputeVisibility and the region manipulation it does.

This is a dumped display list for the GMail folder view. There are 1353 display items, of which 565 are nsDisplayClip. That seems excessive!

I'm going to take this off the blocker list. Scrolling GMail is not really slow at this point. If anyone disagrees, renominate with some performance data and a definition of what "slow" means :-)

(In reply to comment #21)
> I'm going to take this off the blocker list. Scrolling GMail is not really slow
> at this point. If anyone disagrees, renominate with some performance data and a
> definition of what "slow" means :-)

Seems fine here, no bad scroll performance or cpu usage during scroll (even on c2d laptop). Should probably be marked as resolved??

I'm going to leave it open because I can still make it a bit faster and it probably is slow for someone :-)

Using the bookmarklet,

1. 4111 ms
2. 3944 ms
3. 3973 ms

on an i945GM, Core Duo laptop.

In comment #15, I posted a time of 521ms. I just ran the bookmarklet again, same machine, same specs and got 1035ms, 1200ms, 871ms, 1105ms and 825ms. Latest nightly build (Built from http://hg.mozilla.org/mozilla-central/rev/c0e05d518f57).

I'm getting 1377ish consistently using build: Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112135818

It's jerky at times when scrolling in GMail.

~B

Shaun, Brian, Bryan: are you using acceleration or not?

I'm not using smooth scrolling, never liked it, and even with the scores I got from the bookmarket, it seems to scroll fine for me.

Graphics (about:support)
Adapter Description NVIDIA GeForce 7950 GT
Vendor ID 10de
Device ID 0295
Adapter RAM 256
Adapter Drivers nvd3dumx,nvd3dum
Driver Version 8.17.12.6099
Driver Date 10-16-2010
Direct2D Enabled false
DirectWrite Enabled true
WebGL Renderer TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 12 2011 04:24:03)
GPU Accelerated Windows1/1 Direct3D 9

Robert, yes I'm using acceleration:

Adapter Description: NVIDIA Quadro FX 4600
Vendor ID: 10de
Device ID: 019e
Adapter RAM: Unknown
Adapter Drivers: nv4_disp
Driver Version: 6.14.12.5981
Driver Date: 9-26-2010
Direct2D Enabled: false
DirectWrite Enabled: true
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 11 2011 15:51:27)
GPU Accelerated Windows: 1/1 Direct3D 9

~B

Let me also add that I'm not using smooth scrolling either.

~B

1000ms is about 50fps which is a reasonable scrolling speed.

Robert, what would be the cause of the occasional jerkiness? I don't have much of anything running on this box. I also noticed that scrolling in gmail using that bookmarklet as well as with my scroll wheel sends CPU up in the high 40's percentage wise.

~B

I don't know, jerkiness is hard to diagnose.

My chipset is completely blocklisted.

Adapter Description: V1.2 Sherry Driver for 945
Vendor ID: 0000
Device ID: 27a2

Adapter RAM: Unknown
Adapter Drivers: igdumdx32 igd10umd32

Driver Version: 1.2.0.9190
Driver Date: 8-15-2010

Direct2D Enabled: false
DirectWrite Enabled: false

WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 12 2011 04:24:03)

GPU Accelerated Windows: 0/1

(This is with all the forced options set to true)

Just retested this with an updated video card. Went from a 7950GT to an 8600GT. Not much of an upgrade, but at least it supports CUDA and DX10. =)

811ms, 770ms, 766ms, 799ms, 775ms

Adapter Description NVIDIA GeForce 8600 GT
Vendor ID 10de
Device ID 0402
Adapter RAM 256
Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version 8.17.12.6099
Driver Date 10-16-2010
Direct2D Enabled true
DirectWrite Enabled true
WebGL Renderer TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 13 2011 03:37:36)
GPU Accelerated Windows 2/2 Direct3D 10

Is there any more data I can submit (using simple tools which give reproducible results) from my entry-level setup which will help the debugging?

(FWIW, I filed bug 629568 on another scrolling slowdown w/ layers enabled, using a bookmarklet similar to the one in this bug. That one appears to be a Linux-specific issue (or at least magnified-on-linux), hence filing a separate bug.)

Wanted to add one note here about CPU use - on a system with not much else running, scrolling looks good to me (~900 ms using the bookmarklet) however this came at a cost of about 65% cpu usage peak. Your bookmarklet in Safari gave me ~600 ms and only a 30% cpu usage.

I can imagine some of these complaints may stem from systems under load. Moving the scroll bar around manually (vigorously!) I could get up to 90% use, Safari peaked at about 30% which eliminates running the bookmarklet as the primary cpu use.

Was using top -s 1 with 10 trials for the cpu.

Build:

Firefox Version 4.0b10 User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 - Direct2D Enabled false | DirectWrite Enabled false WebGL Renderer ATI Technologies Inc. -- ATI Radeon X1600 OpenGL Engine -- 2.0 ATI-1.6.24GPU Accelerated Windows0/1

Safari Version 5.0.3 (6533.19.4)

What if you open a chat window?

Chat window open is about the same as no chat window in Firefox. However chat window minimized look like ~100 ms more.

For whatever reason my Safari performance has tanked though and isn't so useful - it's 2700 ms now without a chat window and 3000 ms with one open. Wish I could tell you why it tanked.. (reset just about everything, restarted and shutdown as well). I'll pipe up again if things look any different.

Chat Window, Pop-out chat window, Google Voice window, etc. They all don't slow down scrolling in GMail for me on Beta 11.

Reading over this, I wonder if the jerkiness might be sessionstore.js saving a whole bunch of data (JSON encoding it, then saving to disk). A simple search on google can leave the tab with 200-800K of sessionstore data to save every time. Even without that, it will tend to interrupt you every few seconds.

See bug 669034 and related

With absolutely no evidence to support this, I'm convinced that this issue could be related to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=680090">680090</a>...at least for certain users.

Since having upgraded to version 6 I've experienced a significant performance slowdown and hangs/freeze (spinning beach ball) sometimes every 2-3 minutes on certain websites. These sites are almost always javascript-intensive ones or sites that rely on lots of nested content (ie: iframes).

I notice this poor behavior particularly when I have many tabs open (FYI: Google maps slows to a crawl--it never used to). Is Google maps possibly something to be looking at to identify this problem? As it stands I'm having to consider reverting to 5.x...it gets so bad.

(In reply to Emlyn from comment #43)
> With absolutely no evidence to support this, I'm convinced that this issue
> could be related to <a
> href="https://bugzilla.mozilla.org/show_bug.cgi?id=680090">680090</a>...at
> least for certain users.

Since the problem has been happening since before 5.x (for me) I don't think so.

*** Bug 280917 has been marked as a duplicate of this bug. ***

Scrolling in Gmail has never been super fast for me. But i could live with it. The "Old Look" with the new Preview theme scrolled my inbox at about 5000ms. With the Classic theme it scrolls about 7000ms (higher info density). CPU spikes to near 100% either way.

Currently on Firefox 8 (beta6)
MacBookPro3,1 - 2.2 GHz Core 2 Duo - GeForce 8600M GT 128MB

But now with Gmail's "New Look" they are rolling out [http://gmailblog.blogspot.com/2011/11/gmails-new-look.html], everything in Gmail seems to be slower, including scrolling. But unfortunately, the bookmarklet to test scroll speeds from Comment #12 no longer works because they changed the arrangement of frames.

Not sure if various Gmail themes or the New Look affect how this bug is approached.

Try the bookmarklet in https://bugzilla.mozilla.org/show_bug.cgi?id=681867#c5

Firefox 12 and 13 have shipped, no point in tracking this bug for them.