User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100817 Minefield/4.0b5pre Build Identifier: As far as I could test, rendering performance was the same, it was just that smooth scrolling was noticeably delayed, specially when trying to scroll after letting go of mouse wheel but before the scroll animation stopped. Reproducible: Always

I can't reproduce this on the latest build from bug 130078.

Probably fixed by bug 588407 as well then I guess, although the relationship isn't quite clear. Thanks for retesting.

Optimistically marking this fixed. If it isn't please re-open.

The link to the try server build I posted in another bug (2050d6216b77) was incorrect, it did not have 130078. Please try one of these try server builds to see if the problem is resolved http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-cf64eea45e07/

Still seeing this with latest build from 130078 :(

Is there something about bug 591435 that I don't know that will fix this bug? Or why is it a dependency on this bug?

(In reply to comment #6) > Is there something about bug 591435 that I don't know that will fix this bug? > Or why is it a dependency on this bug? Right now I'm only seeing this with D2D disabled and when loading background tabs. Wouldn't bug 591435 fix this issue?

Still seeing this?

(In reply to comment #8) > Still seeing this? I did some testing versus a pre-bug 130078 build and I can't see a difference when D2D is on, but without D2D there is a small performance regression when loading background tabs. In both builds scrolling stutters when opening a heavy page like Tinderbox or various random pages, but the post-bug 130078 build seems to perform worse. It's much better than it was when I first reported this bug tho, and things like bug 590260 and bug 586201 landed between nightlies (which might somehow influence what I'm seeing?) so unless there's something obvious to fix here you can probably close this bug.

Would you be willing to investigate some of the inbetween nightlies to see what made us better/worse? Ideally we wouldn't have gotten worse at all here.

I tested http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1283485308/ (rev 7aaf30721c48, post bug 591435) versus http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-26-12-mozilla-central/ (rev 0e40a49c27bb, pre bug 130078, 590260 and 586201). There seems to be a nightly after bug 586201 which I missed, but the next nightly already contains bug 130078 and 590260 (which is where the regression first appears) and hourlies between those pushes are not available. If you meant nightlies after bug 130078 but before the recent build I used then there were actually performance wins. But yes I would be willing to help testing any builds that could have regressed this.

I'm not going to block on this. If we want to block on scrolling performance, please provide concrete testcases.

This bug talks about pages loading in background tabs. So I think that the fix for the perf issue mentioned in bug 593457 will help here.

The perf regression from bug 130078 seems to be gone, however loading background tabs is still painful. It doesn't seem to be painting related anymore tho, as doing for instance a search on bugzilla will also cause stuttering during scrolling on the foreground tab. If it's I/O related could bug 549767 help here? Anyway I'm going to close this bug since the initial issue when this bug was reported is now fixed and file a followup to see if there's any way to reduce performance hit of loading background tabs.

I'm still seeing this but when I turn off direct2d and d3d layers. I also noticed that in this configuration with smooth scrolling enabled, Minefield uses 5-8x more cpu resources than Firefox 3.6.9 does. The cpu load is also evenly shared across two cores at roughly 35-50%.

Are you using a 2010-09-12 nightly or newer to test?

Yes I am, 2010-09-11 build was even worse. I made sure 594267 had landed before reporting the issue.

For people who see this, can you describe what it is that you are seeing? Jerkiness? Slowness? CPU usage?

I see general slowness in scrolling and high cpu usage. (ONLY when I've disable hardware acceleration, d2d AND layers) 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();})()) Using that bookmarklet on this page, on different versions of Firefox and various configurations of Minefield, I get the following results: Minefield D2D+D3D9 Layers OFF: 1861ms Minefield just D3D9 Layers ON: 501ms Minefield just D2D ON: 481ms Minefield D2D+D3D9 Layers ON: 512ms Firefox 3.6.10: 610ms In all versions/configurations smooth scrolling was on.

Thanks for those numbers. I tried those steps with all acceleration off and I got about 600ms with 3.6 and about 500ms with the latest nightly (tried them both many times). Do you think you could try some other nightlies to see when the "all acceleration off" numbers got worse for you?

When testing you should do a few trials to make sure the numbers are stable and have only one tab (because there were some problems if you had other background tabs open for a while in nightlies). Of course if there is a regression with more than one tab in current nightlies we should investigate that as well.

Yes, its even worse with a background tab open, in the 5000ms region. (actually it depends on the tab open, pages without plugins tend to make little difference) Interestingly, even though smooth scrolling perceptually feels a lot worse than normal scrolling, it turns out I get exactly the same results with smooth scrolling on or off with this bookmarklet. Its just that smooth scrolling just feels a lot slower whereas normal scrolling feels worse but not by as much. Does this mean i'm posting on the wrong bug? Will try to find a regression range. Who knows maybe the issue i'm experiencing might not even be related to bug 130078. In which case, sorry wasting your time.

It doesn't matter which bug caused this, if there is a problem we should figure it out. You say that it is worse with background tabs. Is that true using the latest nightly? How does 3.6 behave? Is it unaffected by background tabs or is it effected less or more?

Bug 596491 has a patch that fixes a regression that is slowing things down when any tab contains a plugin.

Yes i'm using the latest nightly. 3.6 isn't really affected by background tabs, plugins or not. Minefield on the other hand is affected by background tabs, but only if that background has flash running. I did some testing with HW acceleration on and this is true here as well, though its not as bad. With D2D+D3D9 Layers ON I get ~700ms. Not ideal but a far cry from the 5000ms with HW accel off.

Let's keep this bug about the situation where there are no background tabs. What page are you benchmarking this on?

I'm benchmarking this page. The regression range is between 26-08 and 29-08. I know that 130078 landed somewhere in this range. 26-08 is fine, 29-08 is slow.

Can you save a copy of this page, or choose another bug that isn't changing anymore?

On this page of static text: http://www.ietf.org/rfc/rfc2631.txt I get ~1800ms Turning off aero(changing the windows theme to Windows 7 Basic) i get: ~500ms Changing to Windows 7 Classic I get: ~1200s I've repeated these test again and again just to make sure. Weird.

OK. We should block on that performance regression.

Ok, I can reproduce a much smaller regression caused by 130078 with glass on the window, about 100-150ms.

Looks like a good chunk of the extra time is spent doing PopGroupWithCachedSurface in BasicLayerManager::EndTransaction because the root layer is not opaque. I wonder if we can be smarter here if we are only drawing over an opaque area (the content area) and avoid pushgroup/popgroup.

Yeah. I think we should change the layers API so that instead of setting an "opaque" flag, we set an opaque region on each layer. Then MayHaveOverlappingOrTransparentLayers can return false if the area of the dirty region is opaque. Matt/Timothy, can one of you take this?

Yeah, I can probably take this.

Timothy: Do you want me to email you 2 xperf .etl logs of the scrolling test, before and after the regression window? Would this help, since my regression is bigger than what you're seeing?

Yes, if you are willing to do that I would definitely take a look.

Any progress on this?

Timothy: Sorry for the delay, sent you those logs.

Does "breaks" here mean "makes much slower"? Could you adjust the bug summary to reflect what exactly is broken?

Asigning to myself to profile and determine what needs to be done here.

(In reply to comment #29) > On this page of static text: > http://www.ietf.org/rfc/rfc2631.txt Here is my numbers for this page, loaded as the only tab in the browser: 3.6.13: 764ms trunk with acceleration and d2d2 turned off: 778ms trunk with acceleration off and d2d on: 763ms trunk with acceleration and d2d turned on: 763ms Are we attacking a useful problem here?

What do you get if you turn off aero glass (so that no part of the main window is transparent)?

We definitely need to do comment #33, the issue shows up in profiles in bug 629866. I was planning to do that ASAP.

(In reply to comment #42) > What do you get if you turn off aero glass (so that no part of the main window > is transparent)? roc, Timothy, if you guys still need the answer to this, I can get it for you tomorrow at the office.

If roc is going to do comment 33 then we don't need it now.

I don't know if it is useful, but I've found a page where scrolling with smooth scrolling enabled is incredibly slow: http://www.omgubuntu.co.uk/ Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110201 Firefox/4.0b11pre

Felt ok on my machine (Linux).

(In reply to comment #46) > I don't know if it is useful, but I've found a page where scrolling with smooth > scrolling enabled is incredibly slow: http://www.omgubuntu.co.uk/ > > Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110201 Firefox/4.0b11pre No idea why but it's ok now, sorry for bugspam.

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

(Note: This with HW accel turned off) From about around 2 months ago the regression went down from 1800~ms to 950~ms and then a couple weeks ago went down further to 850ms. However the 2011-02-10 nightly shows no improvement for me. Although i noticed something weird a couple weeks ago. The regression completely disappears if i resize Minefield to about half the width of the screen and play a video in VLC, and then run the bookmarklet while the videos playing. An even weirder thing is that it doesn't work as well with WMP but does work well with MPC which is also DirectShow based. WT... F?

(In reply to comment #50) > Although i noticed something weird a couple weeks ago. The regression > completely disappears if i resize Minefield to about half the width of the > screen. I've been running into this for the last week or so. Seems completely random, happens a lot on bugzilla pages. Resizing inward always gets things going again.

Anybody want to try this try build http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/cpearce@mozilla.com-09f7f419b279/ and see if anything is changed?

The try build has been moved to here now http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/old/cpearce@mozilla.com-09f7f419b279/

(In reply to comment #51) > (In reply to comment #50) > > Although i noticed something weird a couple weeks ago. The regression > > completely disappears if i resize Minefield to about half the width of the > > screen. > > I've been running into this for the last week or so. Seems completely random, > happens a lot on bugzilla pages. Resizing inward always gets things going > again. That is similar to an issue I've been trying to figure out. However, it affects more than scrolling. It will affect the entire OS until the a full focus change is made. Clicking on the taskbar to try and shift the focus won't work. However minimizing or starting another app usually does it. The last time I tried to do a profiling with CodeAnalyst, unfortunately it calls CMD.exe to start the test which causes a brief focus change. Resizing Firefox also clears it up, though the resizing can be even very small instead of half of the app. To resolve it I normally pull the window from the top with Aero Snap and put it back the way it was. Usually Firefox is maximized and the resizing is very slight. (Matter of fact, I ran into it just now typing this into the comments form.)

Is the cpu use actually high? Maybe its just not repainting for some reason?

** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons: - it was marked as a soft blocking issue without a requirement for beta coverage