Closed Bug 579260 Opened 14 years ago Closed 12 years ago

Gmail scrolling is slow

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
relnote-firefox --- 20+

People

(Reporter: roc, Assigned: roc)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

GMail folder view display list
141.98 KB, text/plain
Details
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.
Blocks: 564991
No longer depends on: 564991
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 :)
blocking2.0: --- → ?
I don't know if bug 581576 is the same issue, if so, please feel free to duplicate and make it block final release.
blocking2.0: ? → beta5+
--> beta6+
blocking2.0: beta5+ → beta6+
blocking2.0: beta6+ → final+
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.
blocking2.0: final+ → betaN+
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.
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 :-)
blocking2.0: betaN+ → -
(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.
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.
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
Firefox 12 and 13 have shipped, no point in tracking this bug for them.
tracking-firefox12: ? → ---
tracking-firefox13: ? → ---
I got this bug in Firefox 14.0.1 too!
gmail scrolls fine in firefox 15.0 and firefox 15.1. however, this as mentioned 2 years ago is still slow: http://upload.wikimedia.org/wikipedia/commons/2/2c/USA_New_Jersey_location_map.svg {click on the image and scroll => slow, click on the white space on the right => fast}
So the release notes link to this bug saying that "For some users, scrolling in the main GMail window will be slower than usual", but from this bug report it is not clear what "usual" means. It could be interpreted as describing a regression, when in fact there is none.
If this helps anyone... I was in the middle of testing some issues with one of my webapp sites, and I noticed when you remove Adobe Flash Player 11+ the scrolling issue seems to resolve itself. I am not sure if that helps, but it is where I got in my testing.
(In reply to ryan.olson from comment #52) > If this helps anyone... I was in the middle of testing some issues with one > of my webapp sites, and I noticed when you remove Adobe Flash Player 11+ the > scrolling issue seems to resolve itself. I am not sure if that helps, but > it is where I got in my testing. I've done and it seems that FF works faster, i.e. no layovers during scrolling or typing in Gmail.
This has been appearing in the release notes for over 2 years now. Is it still a big enough issue that it warrents the keywords=relnote, or can I just remove it?
I think we can remove it in FF19.
(In reply to ryan.olson from comment #52) > If this helps anyone... I was in the middle of testing some issues with one > of my webapp sites, and I noticed when you remove Adobe Flash Player 11+ the > scrolling issue seems to resolve itself. I am not sure if that helps, but > it is where I got in my testing. When I load GMail today (in Firefox nightly), even when Flash is enabled it doesn't get loaded by GMail. (You can tell because there's no plugin-container or Flash process created as a child of the firefox.exe process.) Is that true for other people?
(In reply to comment #56) > (In reply to ryan.olson from comment #52) > > If this helps anyone... I was in the middle of testing some issues with one > > of my webapp sites, and I noticed when you remove Adobe Flash Player 11+ the > > scrolling issue seems to resolve itself. I am not sure if that helps, but > > it is where I got in my testing. > > When I load GMail today (in Firefox nightly), even when Flash is enabled it > doesn't get loaded by GMail. (You can tell because there's no plugin-container > or Flash process created as a child of the firefox.exe process.) > > Is that true for other people? Not for me. Gmail seems to use Flash for me all the time. Do you have chat enabled? I think that's how they play sounds in chat.
Right, I see the plugin loaded when I activate chat. Thanks. The plugin element is 100x100 but it's in a 0x0 IFRAME, so is always invisible. That means nsRootPresContext::ComputePluginGeometryUpdates gets false for aBuilder->ContainsPluginItem() (since no plugin was found) and we don't take the slow display list analysis path since we know no plugins are visible. So comments #52 and #53 should no longer apply; since bug 642257, enabling/disabling Flash should not affect paint performance on GMail. That fix will ship in FF18. ryan.olson, jbuczny: it would be great if you can confirm that disabling Flash no longer makes a different in FF18 (Beta) or newer. Thanks!
blocking2.0: - → ---
Depends on: 642257
OS: Mac OS X → All
Hardware: x86 → All
Per comment 55, can we now remove the keyword? (Or is this even fixed enough to close the bug?)
Keywords: relnote
I would suggest it's fixed
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
As its going fast for me
Resolution: FIXED → WORKSFORME
Remove it as a known issue on the release notes.
removing from 20 beta notes.
relnote-firefox: --- → 20+
I encounter this problem again. Could anyone confirm?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: