User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre Somewhere around September 2nd, I would hazard a guess, scrolling performance regresses significantly. The browser has hard time scrolling sites with average complexity (see URL example). Reproducible: Always Steps to Reproduce: 1. Open Browser 2. Go to some website 3. Scroll up and down Actual Results: Scrolling speed / performance is bad - a lot worse than it was before. That is, scrolling skips / laggs. Expected Results: Scrolling should be as fast as it was last week. It is slower without hardware acceleration than it was. It is slower with hardware acceleration than it was.

There's also UI lag when clicking on the items in the menu bar. It feels like there's a latency interposed between the cursor and the actual display of mouse hover or click.

I've noticed the scrolling regression as well, especially when scrolling with scroll wheel. More noticable at certain sites, for example at www.aftonbladet.se (swedish news site). Running W7 with hardware acceleration ON (D2d and layer). Decent computer: Intel quad core Q6600 and DX 10.1 graphics card (ATI 3870)

Guys, since yesterday ( 2010-09-17 ), I'm having boring performance issues in minefield, after updating. Scrolling seems very slow, like open/closing a tab, open panorama, and another things. Sometimes, minefield change the aero glass theme to aero basic. I'm using a notebook with an Intel GMA 965 integrated video card (maybe, can this be the reason of the bug/issue ?), and I think, hardware acceleration is not yet compatible. Thanks friends.

Problem goes away if you switch to full screen mode (F11). Seems like the the whole window is rendered on a glass surface when in windowed mode, that causes the overhead. Anyway, it has to be fixed, as browsing is now painful on my Intel GMA950 (and remember, Intel has the biggest market share in the GPU business).

Thanks Goose. You nailed the problem. The temporary solution is to disable Desktop Composition when using Firefox.

Try disabling accelerated layers in about:config - layers.accelerate-all Or 2d acceleration - gfx.direct2d.disabled To see if these setting have an impact on the regression. Please post your about:support Graphics section if they do.

Also, check what about:support has to say in the graphics section!

Hey Jim, thanks, it worked for me. Changing layers.accelerate-all to false, give me an immediately gain of performance. The scrolling still a little bit slow, but the other issues wich a said before, gones perfectly. This can be a temporary solution for this bug. Thanks.

Hi Jim, disabling all acceleration still retains even the UI lag. i945GM.

(In reply to comment #8) > Hey Jim, thanks, it worked for me. Changing layers.accelerate-all to false, > give me an immediately gain of performance. The scrolling still a little bit > slow, but the other issues wich a said before, gones perfectly. This can be a > temporary solution for this bug. Thanks. (In reply to comment #9) > Hi Jim, disabling all acceleration still retains even the UI lag. i945GM. If possible, could you both post the "Graphics" info from about:support?

Graphics Adapter Description Mobile Intel(R) 945 Express Chipset Family Vendor ID 8086 Device ID 27a2 Adapter RAM Unknown Adapter Drivers igdumd32 Driver Version 8.15.10.1930 Driver Date 9-23-2009 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 0/1

Sorry guys, after reboot the PC, the lags still hapening. Here is my graphics info: Adapter Description: Mobile Intel(R) 965 Express Chipset Family (Microsoft Corporation - WDDM 1.1) Vendor ID: 8086 Device ID: 2a02 Adapter RAM: Unknown Adapter Drivers: igdumd32 igd10umd32 Driver Version: 8.15.10.1749 Driver Date: 5-6-2009 Direct2D Enabled: false DirectWrite Enabled: false GPU Accelerated Windows: 0/1

Sorry guys, after reboot the PC, the lags still hapening. Here is my graphics info:Adapter Description: Mobile Intel(R) 965 Express Chipset Family (Microsoft Corporation - WDDM 1.1)Vendor ID: 8086Device ID: 2a02Adapter RAM: UnknownAdapter Drivers: igdumd32 igd10umd32Driver Version: 8.15.10.1749Driver Date: 5-6-2009Direct2D Enabled: falseDirectWrite Enabled: falseGPU Accelerated Windows: 0/1

Speaking about example URL provided (random forum thread), Disabling Glass on W7 -> No Effect. Direct2D Enabled -> Major improvement. HW Layers Enabled -> Minor improvement. Both Enabled -> Best; Almost Chrome-like. HP Mini 311 Netbook, CPU: 2.3 Memory (RAM): 4.5 Graphics: 4.5 Gaming Graphics: 5.4 Primary HD: 5.3

(In reply to comment #14) > Speaking about example URL provided (random forum thread), > > Disabling Glass on W7 -> No Effect. > Direct2D Enabled -> Major improvement. > HW Layers Enabled -> Minor improvement. > Both Enabled -> Best; Almost Chrome-like. > > HP Mini 311 Netbook, > CPU: 2.3 > Memory (RAM): 4.5 > Graphics: 4.5 > Gaming Graphics: 5.4 > Primary HD: 5.3 Well, to be fair, a Mini 311, I happen to have one myself, is a pretty slow device. For me, it doesn't scroll that page particularly smooth in any version of chrome of FF with any prefs :).

My gfx details: Adapter Description: Mobile Intel(R) 945 Express Chipset Family: Vendor ID8086 Device ID: 27a2 Adapter RAM: Unknown Adapter Drivers: igdumd32 Driver Version: 8.15.10.1930 Driver Date: 9-23-2009 Direct2D Enabled: false DirectWrite Enabled: false GPU Accelerated Windows: 0/1 I can't really play with HW acceleration switching, nothing is supported on my PC. The only thing that really explodes performance is switching to fullscreen mode with F11.

(In reply to comment #15)> (In reply to comment #14)> > Speaking about example URL provided (random forum thread),> > > > Disabling Glass on W7 -> No Effect.> > Direct2D Enabled -> Major improvement.> > HW Layers Enabled -> Minor improvement.> > Both Enabled -> Best; Almost Chrome-like.> > > > HP Mini 311 Netbook,> > CPU: 2.3> > Memory (RAM): 4.5> > Graphics: 4.5> > Gaming Graphics: 5.4> > Primary HD: 5.3> > Well, to be fair, a Mini 311, I happen to have one myself, is a pretty slow> device. For me, it doesn't scroll that page particularly smooth in any version> of chrome of FF with any prefs :).Doh! My bad! I should mention that I block advertisements!So that website scrolls fine even in battery-saving mode on SRWare Iron (Chrome 6) and it did scroll smoothly for me using Firefox 4 (before September) as well.

OK time for a little update. Intel drivers had serious bugs that are only fixed in the newest version for each given (graphics card, windows version) combination. So you need to upgrade to your latest driver version. For example, the driver in Comment 12 is too old. Blacklisting of bad Intel driver versions was implemented last week. So if you run a nightly, it will disable HW accel rather than crashing (on Intel/Windows). Blacklisting for other GPUs / OSs is coming soon. Only D3D9 (with good enough shaders) / OpenGL 2 capable hardware is useful here. So I doubt that there's much that a Intel 945 will be of any use.

That doesn't sufficiently explain why the entirety of Minefield lags badly and easily pegs 1 core at 100% when Desktop Composition is on, and scrolls/loads/responds smooth as silk with minimal CPU load when DC is off.

Are there any updates for this bug? Minefield is snappy and very fast when Desktop Composition is disabled, but still sucks up CPU time when DC is enabled.

(In reply to comment #20) > Are there any updates for this bug? Minefield is snappy and very fast when > Desktop Composition is disabled, but still sucks up CPU time when DC is > enabled. Is there any chance you could try and work up a regression date? Nightly builds are here - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ Just pick a date you feel things were ok and bisect from there. This would really help us nail down the cause.

I will try to nail down the hourlies soon. Preliminarily, the Sept 2 nightly was normal. The Sept 3 nightly was laggy.

Here are the relevant threads from the Mozillazine forums: Sept 02: http://forums.mozillazine.org/viewtopic.php?f=23&t=1982807 Sept 03: http://forums.mozillazine.org/viewtopic.php?f=23&t=1983527 I noticed that Hera made the same observation of slowness on page 6 of Sept 02: http://forums.mozillazine.org/viewtopic.php?p=9841025#p9841025

Can someone who has this bug get us a regression window? Instructions are here: https://wiki.mozilla.org/QA/Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows (Shaun, ping re comment 22 :) )

You can try using the javascript in bug 593389 comment 1 to get an objective measure of scrolling performance on different pages.

Sorry, I tried opening Firefox with a new profile in the older builds (Sept 01-03) but unless I open them in Safe Mode, they crash. It seems that the scroll lag also occurs to the Sept 02 nightly.

What is the crash signature? Do they still crash if you disable hardware acceleration?

How do I get crash signatures when the browser crashes even before the Profile Manager and preventing me from creating a new profile? It happens even though I disabled Layers All (enabled Layers None) and Direct2D, which seems unnecessary because my chipset is blacklisted (maybe hence the lagginess). It happens even though I turned off all the JIT options. It can't be that the Profile Manager actually initialises the prefs of the current default profile, can it?

It doesn't submit a crash that appears in about:crashes after? That could very well be. Can you just create one new profile using a good build, setup all the prefs to disable everything, and re-use that profile on the older builds? You don't need a new profile every time. Also the pref to turn off D2D changed names in the past month, from mozilla.widget.render-mode to gfx.direct2d.disabled. So be sure to have both set. If you're hardware was blacklisted, then in builds before it was blacklisted, that might be the cause of the crashes. Hope this helps.

Aug 01 build: http://crash-stats.mozilla.com/report/index/bp-31c0a1b8-45bd-413a-a24b-510cc2100929 I noticed that important dialogs like the Options window, setting Firefox as default browser, Save Tabs Before Quitting, and Profile Manager come up with a border but transparent surface. The surface is transparent, but if I remember where the buttons are, I can still clickthrough to, eg, save my tabs for next session.

Ok, so that is a crash in your Intel graphics driver. What if you start Firefox in safe mode (-safe-mode)?

2010-07-01-04-mozilla-central Scrolls completely fine in Normal Mode with culprit pref ON. 2010-07-05-04-mozilla-central Scrolls completely fine in Normal Mode with culprit pref OFF. Crashes with pref ON. 2010-07-20-04-mozilla-central Scrolls completely fine in Normal Mode with culprit pref OFF. Crashes with pref ON. 2010-08-20-04-mozilla-central Scrolls with increased CPU%, but perceived latency is negligible. 2010-09-01-04-mozilla-central Scrolling easily pegs CPU at 100%. mozilla.widget.accelerated-layers is the culprit pref! *mad* those were the days (July) of the white background upon startup. Do I work backwards from the Aug 20th build to find parity in CPU usage with Desktop Composition on/off, or work forward to find the first build which lags severely? Gotta stop for now, will be back soon.

So, this seems to be two bugs then, - Legacy GPUs are not being blocked. - General Performance Regression. ?

Shaun, I don't think you need to test with mozilla.widget.accelerated-layers on, we already know that your GPU has problems with it. Try narrowing the 2010-08-20 to 2010-09-01 range first. We can look into the other one after we've figured this one out. Thanks for doing this!

2010-08-25-06-mozilla-central Increased CPU%, negligible perceived latency. 2010-08-27-04-mozilla-central Increased CPU%, slight perceived latency. Initial white Content area bug. 2010-08-28-04-mozilla-central 100% CPU lag. Options dialog transparent look. Seems like solving the white Content area startup bug broke something for blacklisted chipsets with zero gfx acceleration? As for that transparent dialog problem again, I ran out of relevant prefs to disable. Didn't cause any crashes though.

The 100% CPU lag is especially bad with the latest build (2009-09-30), so I suppose there is at least another "feature" causing the persistent problem. That may be whatever was added on between 2009-09-02 and 2009-09-03.

My bad, change all the 2009 to 2010.

Latest builds (this week) for me cause insane CPU strain (Typed text takes some time to show up) when replying on Neowin.net forums (FF unique behavior). This behavior is not not new, but is back with the newer builds. File separate bug?

(In reply to comment #35) > 2010-08-25-06-mozilla-central Increased CPU%, negligible perceived latency. > 2010-08-27-04-mozilla-central Increased CPU%, slight perceived latency. > Initial white Content area bug. > 2010-08-28-04-mozilla-central 100% CPU lag. Options dialog transparent look. > > > Seems like solving the white Content area startup bug broke something for > blacklisted chipsets with zero gfx acceleration? > As for that transparent dialog problem again, I ran out of relevant prefs to > disable. Didn't cause any crashes though. http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-27&enddate=2010-08-28 That points to bug 130078. What did you mean by "Initial white Content area bug."?

The temporary white Content area startup bug which everybody was complaining about back then.

Yup the landing of 130078 was when the buttery-smooth scrolling of Compositor was completely lost.

This page lags in scrolling superbly badly, but was also buttery-smooth when Compositor initially landed. http://fixedbackground.blogspot.com/

(In reply to comment #42) > This page lags in scrolling superbly badly, but was also buttery-smooth when > Compositor initially landed. > http://fixedbackground.blogspot.com/ What do you mean when you say "Compositor"? Are you referring to retained layers?

Yes. The major patch that roc landed. Sorry, the names have been changing around too much.

This problem also happens for me with XP SP3. Even with Bug 593678 resolved I'm still seeing this problem on my Intel 965 / X3100. Another easy site to see this problem is www.spaceflightnow.com or a decently long Bugzilla page. Holding down PgDn and then PgUp to rate performance and to avoid getting into mouse driver questions. Create fresh profile with Layers turned off I can scroll properly up and down test pages several times with good performance and browser doesn't stall. Create another fresh profile with Layers turned on I can scroll maybe 1 or 2 times, slower pace than with layers off, but then it gets totally bogged down and lags out. It will eventually come back to normal if you leave it. I can move my mouse cursor during these stalls, so I know the machine isn't completely max'ed out. Would Adapter RAM not being checked properly have any influence here? (Bug 591787) Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20101004 Firefox/4.0b7pre Adapter Description Mobile Intel(R) 965 Express Chipset Family Vendor ID 8086 Device ID 2a02 Adapter RAM UnknownAdapter Drivers igxprd32 Driver Version 6.14.10.5218 Driver Date 1-13-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows1/1 Direct3D 9 Built from http://hg.mozilla.org/mozilla-central/rev/192c38466579

Does anyone else see improved performance if the Add-on Bar is re-enabled? (View - Toolbars - Add-on Bar) I can't create the problem if I make it visible. Turn it off and I'll get the scrolling problem.

That's interesting.

Some inspiration, :) 1. Get low-end PC. 2. Disable D2D and accelerated layers. 3. Go to neowin.net 4. Scroll page, notice it skipping a lot, horribly slow. 5. Run Firefox 3.6 6. Go to neowin.net 7. Scroll page, notice fairly smooth performance. 8. Enable D2D and accelerated layers in FF4 9. Using FF4, Scroll neowin.net 10. Notice same performance as FF3.6

(In reply to comment #48) > 4. Scroll page, notice it skipping a lot, horribly slow. When you say "scroll page", what do you mean exactly? Do you mean with smooth scrolling on or off? Do you mean using the mousewhell? Dragging the scrollbar? Pageup/pagedown? Arrow keys?

(In reply to comment #49) > (In reply to comment #48) > > 4. Scroll page, notice it skipping a lot, horribly slow. > > When you say "scroll page", what do you mean exactly? Do you mean with smooth > scrolling on or off? Do you mean using the mousewhell? Dragging the scrollbar? > Pageup/pagedown? Arrow keys? Any method of scrolling, - middle-click + drag - up/down arrow keys - mouse wheel (not as noticeable) - pulling the slider - etc. Arrow keys are ideal as smooth motion downward/upward is expected. general.smoothScroll;false Mouse wheel is faster by design - it jumps some pixels (100 pixels?). PG-UP / DOWN are even faster by design - they jump a whole page. Needless to say, they are all slower than in FF3.6 Neowin and its forums are the worst case of this. Also, - I cannot reproduce Comment 46. - This is not "scroll w. mouse over link -> stuttering" bug - It is also not likely to be a flash plugin bug; I block ads. - I refreshed my profile when D3D10 layers landed, it didn't help.

I'm honestly having problems re-creating my Comment 46 now. I'm on 20101005 Firefox/4.0b7pre now and can't recreate my own original test case. Neowin forum scrolling don't seem to cause the gross lag I was seeing before. Since my last test I have rebooted my system a couple of times, instead of the usual "Suspend to Hard Drive" I've been doing. Power settings also got adjusted as well, which may explain some difficulty in recreating it.

I wonder if this has to do with the paint starvation fixes that bug 130078 turned off.

Another observation, Scrolling lagg is not uniform; it is smooth at the very top and bottom of the page. That is, when ~100 px from top or bottom, it becomes smooth. This doesn't work in both directions: When on top, scrolling upwards is smooth, but downwards it is not and vice-versa.

Scrolling with Desktop Composition on (Aero Glass doesn't actually have to be on) is now much more responsive on an Intel GMA w/o any HW Accel, but still pegs one CPU at 100%. The scrolling with Desktop Composition off is still the minimal-CPU ideal case.

Anybody else see any difference since 2010-10-09?

Timothy, isn't this a dupe of bug 588402? They are both about the same issue and they are both a regression from bug 130078.

Maybe. But it doesn't hurt to leave them both open to make sure that they both get fixed, which is what I think I would prefer right now.

I'm not sure if this is the same issue, since some of the above contradicts the symptoms I see (eg the problem goes away if I enable hardware acceleration - and there seemed to be some confusion above as to whether it should be on or off?), but one of the regression ranges above matches, so want to check before I break it out as another bug... Description: CPU usage when autoscrolling using middle mouse button click now 30-40% (up from 0-5%) as of 28th Aug 2010 nightly, iff hardware acceleration turned off. STR: 1) Load nightly being tested, ensure hardware acceleration disabled, restart to apply change. 2) Visit a long page eg: https://bugzilla.mozilla.org/show_bug.cgi?id=598466 3) Click the scroll wheel and move the mouse downwards, to start auto-scrolling. 4) Observe CPU usage using process explorer/task manager, whilst scrolling taking place. Expected: - CPU usage 0-5%. Actual: - In 27th Aug build, CPU usage 0-5% (using C2D 2.4GHz) - In 28th Aug build, CPU usage 30-40% (using C2D 2.4GHz) Regression range using MozRegression: - Last good nightly: 2010-08-27 First bad nightly: 2010-08-28 - Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124

Sorry for the bugspam, missed this off: - The issue I describe in comment 58 still exists in latest nightly (2010-12-05) using Win7. - It also occurs even if desktop composition disabled in Win7 performance options settings.

I tried a different computer: Athlon II P340 (2.2Ghz) && ATI 4250 Mobile. Same issue. Without D2D, Neowin still massively stutters when scrolling. It is not anywhere as bad as on my netbook - considering that this CPU is much faster than Atom. Direct2D does NOT stop the stuttering when scrolling, but it does decrease it. With Athlon 2 P340 laptop, I get stuttering scrolling this page using the arrow keys with full hardware acceleration enabled. Any chance of this being fixed in Beta 9?

lmesa, targeting some beta feedback questions around scrolling would be good in beta8 or beta9. if scrolling performance seems ok in the general feedback then this probably shouldn't block. if general feedback suggests poor scrolling is frequently seen then this might be a good bug to investigate.

Some quick tests from my netbook (Atom, ION), NEOWIN.NET Chrome 8 : 764ms/728ms/816ms/749ms FF3.6 : 881ms/757ms/804ms/804ms FF4 b3 : 850ms/1208ms/922ms/1023ms FF4 b10pre + NO HW Accel : 3201 ms / 3209 ms / 3213 ms / 3221 ms FF4 b10pre + layers : 2873 ms / 2878 ms / 3099 ms / 3361 ms FF4 b10pre + D2D + layers : 1258 ms / 1256 ms / 1258 ms / 1261 ms THIS BUG REPORT, Chrome 8 : 801 ms / 820 ms / 839 ms / 859 ms FF3.6 : 917 ms / 776 ms / 788 ms / 787 ms FF4 b3 : 878 ms / 864 ms / 969 ms / 896 ms FF4 b10pre + No HW Accel : 3384 ms / 3356 ms / 3663 ms / 3361 ms FF4 b10pre + layers : 1167 ms / 1213 ms / 1290 ms / 1195 ms FF4 b10pre + D2D + layers : 1563 ms / 1593 ms / 1535 ms / 1549 ms And here is my notebook, NEOWIN.net Chrome 8: 509 ms / 509 ms / 510 ms / 517 ms FF3.6 : 611 ms / 580 ms / 608 ms / 588 ms FF4 + D2D + Layers : 701 ms / 736 ms / 621 ms / 715 ms FF4 + Layers : 1256 ms / 1104 ms / 983 ms / 977 ms FF4 + NO HW Accel : 1154 ms / 1047 ms / 963 ms / 1006 ms

(In reply to comment #62) > Some quick tests from my netbook (Atom, ION), > > NEOWIN.NET > > Chrome 8 : 764ms/728ms/816ms/749ms > FF3.6 : 881ms/757ms/804ms/804ms > FF4 b3 : 850ms/1208ms/922ms/1023ms > > FF4 b10pre + NO HW Accel : 3201 ms / 3209 ms / 3213 ms / 3221 ms > FF4 b10pre + layers : 2873 ms / 2878 ms / 3099 ms / 3361 ms > FF4 b10pre + D2D + layers : 1258 ms / 1256 ms / 1258 ms / 1261 ms > > THIS BUG REPORT, > > Chrome 8 : 801 ms / 820 ms / 839 ms / 859 ms > FF3.6 : 917 ms / 776 ms / 788 ms / 787 ms > FF4 b3 : 878 ms / 864 ms / 969 ms / 896 ms > > FF4 b10pre + No HW Accel : 3384 ms / 3356 ms / 3663 ms / 3361 ms > FF4 b10pre + layers : 1167 ms / 1213 ms / 1290 ms / 1195 ms > FF4 b10pre + D2D + layers : 1563 ms / 1593 ms / 1535 ms / 1549 ms > > And here is my notebook, > > NEOWIN.net > > Chrome 8: 509 ms / 509 ms / 510 ms / 517 ms > FF3.6 : 611 ms / 580 ms / 608 ms / 588 ms > > FF4 + D2D + Layers : 701 ms / 736 ms / 621 ms / 715 ms > FF4 + Layers : 1256 ms / 1104 ms / 983 ms / 977 ms > FF4 + NO HW Accel : 1154 ms / 1047 ms / 963 ms / 1006 ms How did you do the measurements? Using the famous scrolltest bookmarklet? I can't reproduce this, although I can confirm it's a little bit slower than FF3.6 with no HW accel. This bug 588402 I think. With D2D+Layers we're faster in all cases though on my machine (Tested on Core i7, GT230M). Another thing to be careful with is the bookmarklet (atleast the one I have) uses a setTimeout, this has a certain resolution and will put a bottom limit on the timing.

(In reply to comment #63) > How did you do the measurements? Using the famous scrolltest bookmarklet? I > can't reproduce this, although I can confirm it's a little bit slower than > FF3.6 with no HW accel. This bug 588402 I think. With D2D+Layers we're faster > in all cases though on my machine (Tested on Core i7, GT230M). > > Another thing to be careful with is the bookmarklet (atleast the one I have) > uses a setTimeout, this has a certain resolution and will put a bottom limit on > the timing. Yes, the JS code bookmarklet. I posted these just simply to show numbers behind this bug report (I also thought of doing a video, but thats PITA), this is fundamentally what the bug Description is all about. IMO, you should be able to reproduce it on a standard-level (USD $300-$400) up-to-date laptop (without background CPU-intensive tasks running). My notebook scrolls much smoother than my netbook, so probably with a higher-end CPU than an Athlon II this will not be noticeable. My Computers, Atom N270, Nvidia ION, 2GB DDR3, 160GB HD, 1080p LCD (HDMI), Windows 7 (Pro.) Athlon II P340, ATi Radeon 4250 Mobile, 3GB DDR2, 320GB HD, 1366x768 LED, Windows 7 (Pro. x86_64) ABP (Dev), DTA! (Dev)

fwiw on my notebooks that support D2D we're all faster than 3.6. But I think the primary regression that needs to be located is the one in no layers and no-d2d. And that one I can repro on any machine. It's not unlikely improving that will also improve the D2D/Layers cases.

Yes what is needed is improvement on scrolling (and general UI responsiveness) versus 3.6 with at most the hardware acceleration that 3.6 already uses. The comparison between scrolling with layers+D2D HA on 4.0 and scrolling w/o layers+D2D HA on 3.6 is an apples to oranges one.

I think we need to do something to try to get a machine that reproduces this scrolling regression wrt 3.6 in the hands of someone who can do something about it.

(In reply to comment #67) > I think we need to do something to try to get a machine that reproduces this > scrolling regression wrt 3.6 in the hands of someone who can do something about > it. I don't think there's any machine that doesn't. 3.6 vs 4 with all HW acceleration turned off is consistently a little faster on every machine I have. This is also pure software so it wouldn't make sense for there to be a big difference between machines.

But people are seeing big differences. Thats the problem we need to understand.

Yeah. I actually expect a small regression on vanilla pages (e.g. no fixed-pos stuff) over 3.6 for people with no H/W acceleration, since we do more work to generate layers. But the results of comment #62 are a completely different kettle of fish. Cameron, can you try the tests in comment #62 on that netbook that we bought?

javascript:void((function(){var%20i=0;var%20start=Date.now();function%20f(){if(++i==50){alert((Date.now()-start)+"ms");return;}window.scrollTo(0,i*5);setTimeout(f,10);}f();})()) is the magic bookmarklet.

I'm also worried about machines that are plenty powerful like the Core 2 Duo in bug 623615 comment 21 (and before/after comments) that show a big regression.

Forgive my ignorance: can someone tell me what settings to change so I can try the "No HW Accel", "layers" and "D2D + layers" configurations on this netbook? Here's the output from about:support FWIW: Adapter Description: Mobile Intel(R) 945 Express Chipset Family Vendor ID: 8086 Device ID: 27ae Adapter RAM: Unknown Adapter Driver: sigxprd32 Driver Version: 6.14.10.4926 Driver Date: 2-15-2008 Direct2D Enabled: false DirectWrite Enabled: false WebGL Renderer: (WebGL unavailable) GPU Accelerated Windows: 0/1

(In reply to comment #73) > Forgive my ignorance: can someone tell me what settings to change so I can try > the "No HW Accel", "layers" and "D2D + layers" configurations on this netbook? > Here's the output from about:support FWIW: > > Adapter Description: Mobile Intel(R) 945 Express Chipset Family > Vendor ID: 8086 > Device ID: 27ae > Adapter RAM: Unknown > Adapter Driver: sigxprd32 > Driver Version: 6.14.10.4926 > Driver Date: 2-15-2008 > Direct2D Enabled: false > DirectWrite Enabled: false > WebGL Renderer: (WebGL unavailable) > GPU Accelerated Windows: 0/1 That chipset doesn't support DX10 I think, so you're not going to be able to test with D2D.

The prefs are listed here http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#3220

neowin.net on this Eee PC 1000 Chrome 8: 775 ms / 707 ms / 711 ms / 768 ms Fx3.6 : 1007 ms / 889 ms / 844ms / 906 ms Fx4.0b3 : 908 ms / 937 ms / 875 ms / 954 ms Fx4b10pre + No HW Accel : 1240 ms / 1208 ms / 1240 ms / 1224 ms Fx4b10pre + Layers : 1303 ms / 1287 ms / 1287 ms / 1303 ms I should note that the times in Fx4b10pre get a lot higher (2xxx ms) if the bookmarklet is run with the mouse cursor over the content of the page. Presumably this is because of the check to see what element has moved under the cursor, as well as the restyling of links and so on. (I didn't test the others with the mouse over the content.)

(In reply to comment #76) > I should note that the times in Fx4b10pre get a lot higher (2xxx ms) if the > bookmarklet is run with the mouse cursor over the content of the page. > Presumably this is because of the check to see what element has moved under the > cursor, as well as the restyling of links and so on. (I didn't test the others > with the mouse over the content.) This is very interesting. I don't think that should increase the time that much.

Let's do some profiling on that machine next week.

In case it is useful, here are times with all of these Firefox configurations running with the mouse cursor over the content area, starting with the page scrolled to the very top and with the mouse cursor right in the middle of the "Show" tab on the page. (Chrome doesn't re-hit test at the mouse cursor position after scrolling.) Fx3.6 : 1131 ms / 953 ms / 982 ms / 1032 ms Fx4.0b3 : 1173 ms / 1156 ms / 1150 ms / 1188 ms Fx4b10pre + No HW Accel : 2100 ms / 2198 ms / 2160 ms / 2175 ms Fx4b10pre + Layers : 2121 ms / 1924 ms / 2077 ms / 2152 ms

I would guess that cursor over part regressed either with 130078 or one of the followups or possibly retained layers.

I went to this site and noticed another bug that I am now filing.

Chris P, can you grab the EEE PC from Cameron and get some xperf profiling going? I can help you analyze the profiles :-)

Another thing that'll be interesting to profile and test is opening the window with less browser chrome. E.g. in the Error Console, do window.open("http://neowin.net", "", "location,width=500,height=500")

I had to muck about in the code for mouse cursor + scrolling (synthmousemoves is what the code calls them) a lot for bug 130078, with patches landing before and after 130078. So it wouldn't surprise me if one of them is responsible for this.

New Profile (New W7 profile and new FF4 profile), HP Mini 311: Neowin.net, no flash adverts, full hardware acceleration, Cursor out + maximized : 1264 / 1298 / 1288 / 1310 Cursor in + maximized : 2177 / 2791 / 2139 / 2510 Cursor in (not over links) + maximized : 1336 / 1288 / 1275 / 1296 Cursor out + Smaller Resolution : 1217 / 1132 / 1135 / 1146 Cursor in + Smaller resolution : 2475 / 1815 / 1517 / 2780 Visually none of these are smooth. - Neowin's drop down menus (such as "Services \/" ) kill performance, when cursor is in scrollable area and goes over them. - Toggling aero doesn't make a difference. SRWare Iron (Chrome 8) + Cursor out + maximized : 1024 / 899 / 902 / 877 SRWare Iron (Chrome 8) + Cursor in + maximized : 938 / null Visually this is perfectly smooth. Chrome almost never opens up the drop down menu for Services on that page, whereas FF4 always does. Also, Full HWA + Cursor Out + maximized + flash adds : 1632 / 1619 / 1645 / 1677 A thread on Neowin Forum, {This IS where it gets really BAD} Full HWA + Cursor Out + maximized: 4144 / 4422 / 4217 / 4205 Firefox idles at 8% CPU. SRWare Iron (Chrome 8) + maximized: 887 / 955 / 1020 / 954 That page did have smilies so the scrolling performance might be due to them.

Is it possible you have your ION GPU in power-saving mode?

(In reply to comment #86) > Is it possible you have your ION GPU in power-saving mode? Adaptive. Setting to prefer High Performance does nothing. High Performance in Power Options. Also, I cannot reproduce the 4### result again - shows up as 12## to 13## with D2D.

(In reply to comment #87) > (In reply to comment #86) > > Is it possible you have your ION GPU in power-saving mode? > > Adaptive. Setting to prefer High Performance does nothing. High Performance in > Power Options. > > Also, I cannot reproduce the 4### result again - shows up as 12## to 13## with > D2D. It's possible you were hit by a bug with relation to bug 626227 (which will be fixed on tomorrow's nightly) if you were using a nightly for this.

Installed IE9 and Opera on HP G62-340US (my notebook), Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110126 Firefox/4.0b11pre FF4 (HW, adblock) : 809ms, 532ms, 530ms, 533ms, 540ms. Chrome 8 (adblock) : 490ms, 498ms, 495ms, 496ms, 496ms. FF4 (no HW, adblock): 980ms, 965ms, 967ms, 912ms, 937ms. FF3.6 (adblock) : 540ms, 545ms, 543ms, 536ms, 541ms. Opera 11 (adblock) : n/a - didn't work. IE9 Beta (HW) : 786ms, 779ms, 784ms, 789ms, 796ms.* IE9 Beta (no HW) : 835ms, 978ms, 878ms, 814ms, 822ms.* *no Flash installed Visual side of things: Opera and IE9 beta are fastest at loading, scrolling, and being stutter-less. Chrome's scrolling performance seems in the middle. FF3.6 & FF4 seem to scroll the least Pixels Per Second compared to other browsers. IE9 beta without smooth scrolling scrolls a bit too fast, with smooth scrolling it is about 2-3 times faster. In FF4, Enabling smooth scrolling still stutters with full HWA. Can this be related to other scrolling bugs (YouTube, about:addons, g-mail)?

Probably not the youtube or about:addons bugs, those have specific problems that are understood.

Could anyone who saw this re-test in a 2011-02-10 nightly or newer and see if anything has changed?

(In reply to comment #91) > Could anyone who saw this re-test in a 2011-02-10 nightly or newer and see if > anything has changed? No.

Two more things I'd like to try here: 1) See how results vary with Aero Glass on/off. 2) Try the patches in bug 629866 to see if they help.

(In reply to comment #93) > Two more things I'd like to try here: > 1) See how results vary with Aero Glass on/off. > 2) Try the patches in bug 629866 to see if they help. 1. No difference with transparency off. 2. Link to the try-build please?

(In reply to comment #93) > Two more things I'd like to try here: > 1) See how results vary with Aero Glass on/off. > 2) Try the patches in bug 629866 to see if they help. I see no significant perf difference with Aero Glass on/off with a build from rev b6d820414fc (locally built opt build). With the 10 patches from bug 629866 applied, I don't see a significant change in performance, I do however see more crashes. I get the following output when crashing, which may give someone some info on the cause... --DOMWINDOW == 11 (03B704F0) [serial = 8] [outer = 04766990] [url = about:blank] *** loading ISO8601DateUtils WARNING: 1 sort operation has occurred for the SQL statement '0x8827cf0'. See https://developer.mozilla.org/En/Storage/ Warnings details.: file c:/cpearce/src/red/objdir/storage/src/../../../storage/src/mozStoragePrivateHelpers.cpp, line 13 9 --DOMWINDOW == 10 (03B711D8) [serial = 11] [outer = 00000000] [url = about:blank] ###!!! ASSERTION: Received "nonqueued" message 49395 during a synchronous IPC message for window 3212274 ("MozillaWindow Class"), sending it to DefWindowProc instead of the normal window procedure.: 'Error', file c:/cpearce/src/red/objdir/ip c/glue/../../../ipc/glue/WindowsMessageLoop.cpp, line 319 ###!!! ASSERTION: Received "nonqueued" message 49395 during a synchronous IPC message for window 328760 ("MozillaHiddenW indowClass"), sending it to DefWindowProc instead of the normal window procedure.: 'Error', file c:/cpearce/src/red/objd ir/ipc/glue/../../../ipc/glue/WindowsMessageLoop.cpp, line 319 ###!!! ASSERTION: Received "nonqueued" message 49395 during a synchronous IPC message for window 15729504 ("nsToolkitCla ss"), sending it to DefWindowProc instead of the normal window procedure.: 'Error', file c:/cpearce/src/red/objdir/ipc/g lue/../../../ipc/glue/WindowsMessageLoop.cpp, line 319 ###!!! ASSERTION: Received "nonqueued" message 49395 during a synchronous IPC message for window 263216 ("nsAppShell:Eve ntWindowClass"), sending it to DefWindowProc instead of the normal window procedure.: 'Error', file c:/cpearce/src/red/o bjdir/ipc/glue/../../../ipc/glue/WindowsMessageLoop.cpp, line 319 WARNING: shutting down early because of crash!: file c:/cpearce/src/red/objdir/dom/plugins/../../../dom/plugins/PluginMo duleChild.cpp, line 633 WARNING: plugin process _exit()ing: file c:/cpearce/src/red/objdir/dom/plugins/../../../dom/plugins/PluginModuleChild.cp p, line 625 nsStringStats => mAllocCount: 148 => mReallocCount: 0 => mFreeCount: 143 -- LEAKED 5 !!! => mShareCount: 22 => mAdoptCount: 0 => mAdoptFreeCount: 0

Video of the issue as it currently stands, http://bit.ly/fY8yg4

Thanks for the video. What method of scrolling are you using in it? Mousewheel, arrow keys, track pad gestures, etc?

(In reply to comment #97) > Thanks for the video. What method of scrolling are you using in it? Mousewheel, > arrow keys, track pad gestures, etc? Arrow Keys, both browsers.

So it looks like Chrome moves the page a lot more per "arrow key" (either a single press or per time period it is held down). What does it look like in a version of Firefox where you don't see this scrolling regression?

(In reply to comment #99) > So it looks like Chrome moves the page a lot more per "arrow key" (either a > single press or per time period it is held down). What does it look like in a > version of Firefox where you don't see this scrolling regression? Just what I said above, nothing new. It seems that FF3.6 and 4 scroll the least pixels per second compared to IE9, Opera, and Chrome when using the arrow keys. Additionally it seems that FF4 skips/stutters/laggs compared to FF3.6 when scrolling a page. Chrome: Scrolls more pixels per second, visually smooth - stutter free. FF3.6 : Scrolls less pixels per second, visually almost smooth. FF4 : Scrolls less pixels per second, stutters/laggs/skips. When scrolling, FF4 seems to re-render the page (to reflect the new scrolled view) at a very low FPS rate (FF4 draws the scrolled view too slowly [thus skipping?] / too few times per second). See posts above for the numbers and comparison against your other competitors.

Cannot reproduce on Athlon XP 3000+, NV 6600, & XP SP3.

(In reply to comment #95) > With the 10 patches from bug 629866 applied, I don't see a significant change > in performance, I do however see more crashes. I get the following output when > crashing, which may give someone some info on the cause... Chris, if you still have the patches around could you send them to try server so Hera could try them?

TryServer builds are available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/cpearce@mozilla.com-09f7f419b279/

TRY SERVER, 10xx - Direct3D 9 - little stutter. 135x - Direct3D 10 - Stutters. 19xx - 0/1 - Painful. TRUNK, 10xx - Direct3D 9 - little stutter. 12xx - Direct3D 10 - Stutters. 18xx - 0/1 - Painful. I have no idea. Anyone who's watching this topic see different results?

Filed bug 635645 on increasing the amount scrolled by using the arrow keys.

With hardware acceleration disabled, I see a big difference in the performance with the mouse hovering the content area, especially if the mouse hovers the "Forum posts" right hand box on the page, which contains a lot of links. Here are the most expensive functions in an xperf profile: Process, Module, Function, DPC/ISR, Weight, % Weight , , sse2_composite_src_x888_8888, Regular CPU Usage, 120.999735, 3.10 , , pixman_fill_sse2, Regular CPU Usage, 78.045953, 2.00 , , sse2_combine_over_u, Regular CPU Usage, 20.991005, 0.54 , , nsIFrame::BuildDisplayListForChild, Regular CPU Usage, 11.012586, 0.28 , , fetch_scanline_a8, Regular CPU Usage, 10.001478, 0.26 , , mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems, Regular CPU Usage, 7.995639, 0.20 , , nsIFrame::GetOffsetToCrossDoc, Regular CPU Usage, 6.000623, 0.15 , , nsDisplayWrapList::GetBounds, Regular CPU Usage, 5.999785, 0.15 , , sse2_composite_over_n_8_8888, Regular CPU Usage, 5.986586, 0.15 , , SelectorMatches, Regular CPU Usage, 4.998959, 0.13 , , nsRegion::SubRect, Regular CPU Usage, 4.004281, 0.10 , , nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity, Regular CPU Usage, 4.000928, 0.10 , , PL_DHashTableOperate, Regular CPU Usage, 3.998623, 0.10 , , nsRegion::InsertInPlace, Regular CPU Usage, 3.998204, 0.10 , , SearchTable, Regular CPU Usage, 3.988705, 0.10 I will also attach the xperf etl output.

Here is my xperf profile: http://people.mozilla.com/~eakhgari/595400.etl.bz2

Why do D3D9 layers provide the smoothest scrolling performance?

So I tried to create an optimized build with --enable-debug-symbols and --enable-profiling and then move it together with the symbols on the target machine and xperf again, but I was unsuccessful. No matter what I tried, xperf refused to resolve stack symbols for the custom build. I don't know what else to try...

However, Timothy, reproducing this seems to be *very* easy. Ping me on IRC if you need help.

(In reply to comment #83) > Another thing that'll be interesting to profile and test is opening the window > with less browser chrome. E.g. in the Error Console, do > window.open("http://neowin.net", "", "location,width=500,height=500") Doesn't seem to improve the numbers.

** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 19 being moved from blocking2.0:betaN+ to blocking2.0:- as we reached the endgame of Firefox 4. The rationale for the move is: - the bug had been identified as a "soft" blocker which could be fixed in some follow up release - the bug had been identified as one requiring beta coverage, thus is not appropriate for a ".x" stability & security release The owner of the bug may wish to renominate for .x consideration.

(er updating flag to "-" as per previous comment!)

This is still really noticeable using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122446. Noming for .x+ given: - was previously a softblocker - number of confirmations above, plus regression range known - particularly poor performance when not using h/w accel/layers (compared to 3.6.x), which is going to be a much more common config outside of nightlies/betas. (Since people in the RW will likely be using older GFX hardware/older drivers, which are more likely to be blocklisted, so have no way of avoiding this issue by enabled h/w accel).

I think we should fix this in the next cycle if we can, but I really don't think we ought to mess with this on the stable branch unless the fix is trivially safe.

Now that the arrow key scrolling speed has been increased, stuttering is more robust/noticeable.

We are going to revamp scrolling for snappy in another bug(TBD)

Not able to reproduce neither on the version it was logged or on Latest builds Nightly 25 or Aurora 24

Still not able to reproduce on latest nightly 27. If anyone can still reproduce it please reopen