Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre ID:20110106030349 Scrolling by mouse wheel lagged. It is remarkable if enabled smooth scrolling. Lagged on any pane. Reproducible: Always Steps to Reproduce: 1. Start Minefield with new profile 2. Open add-ons manager( Ctrl+Shift+a ) 3. Scrolling by mouse wheel on any pane (enabled smooth scrolling) Actual Results: Scrolling by mouse wheel lagged Expected Results: Scrolling by mouse wheel should not lag

Could this be related to how the list entries are getting drawn, i.e. rounded borders, or any SVG related objects?

U dont think dup, No cpu spike.

s/U/I/

Regression window: Works(Slow scroll but mot lagged): http://hg.mozilla.org/mozilla-central/rev/e3b1c75995ac Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104030354 Fail(too much lagged and choppy): http://hg.mozilla.org/mozilla-central/rev/2a0d0ed04874 Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104005658 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e3b1c75995ac&tochange=2a0d0ed04874

Robert: This sounds like it could be a performance regression from bug 602892.

Inlocal build, build from 2a0d0ed04874 : too much lagged and choppy build from e870951c9167 : Slow scroll but not lagged build from c3825c079c00 : ditto build from 35013af94ec7 : ditto build from aa5e8e362cb2 : ditto build from e3b1c75995ac : ditto suspect: 2a0d0ed04874 Robert O'Callahan — Bug 602892. Part 2: Ensure that a scrollframe is 'inactive' if it can't be scrolled by blitting. r=tnikkel,a=blocking

Yes bug 602892 was expected to cause this exact situation to slow down, it was a correctness fix so scrolling looked visually correct.

If you just removed the almost invisible rounded corners from the addon manager panes, this problem (and others) would go away.

(In reply to comment #9) > If you just removed the almost invisible rounded corners from the addon manager > panes, this problem (and others) would go away. Confirmed with the following userChrome.css. #view-port-container { border-radius: 0px !important; }

s/userChrome.css/userContent.css/

Adding the code Alice0775 came up with in Comment #10 to userContent.css, knocked the CPU usage I mentioned at https://bugzilla.mozilla.org/show_bug.cgi?id=623739#c4 to <= 20% (in about:addons->Extensions/Appearance/Plugins). This fix, actually makes scrolling in (smooth or normal) and use of the Add-ons Manager work again.

It has been happening to me for a quiet long time. Very annoying bug.

Or just simply do a circle movements with your mouse in Add-ons Manager in Get add-ons tab.

The CSS code that Alice0775 provided doesn't help. Scrolling is still very laggy and spikes 1 CPU to more than 80%. i945GM, Core Duo.

Shaun, you also posted very slow numbers for the gmail scrolling bug. I wonder if there is something specific about your machine or profile that is causing very slow scrolling. Would you be willing to try a fresh profile? Or comparing your numbers on a simple page (say bugzilla) or comparing your numbers to numbers from Firefox 3.6?

The GMail bookmarklet code works only on the GMail page, doesn't it? How do I modify it to make it work on any page (or a Bugzilla page)? Scrolling is perceptibly fine here and on, say, the Mozillazine forums.

Oh sorry, you can use this bookmarklet on any page 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();})()) (gmail puts all its content inside an iframe so needs a special version of this bookmarklet)

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 **Completely new profile created in latest 4.010pre** Gmail scrolling (default zoom): 3299 ms 3208 ms 3331 ms 3310 ms 3297 ms Gmail scrolling (zoomed 3 mouse clicks): 3242 ms 3548 ms 3443 ms 3523 ms 4075 ms (if cursor hovers over labels) Scrolling in this bugzilla page (default zoom): 2319 ms 2432 ms 2295 ms 2304 ms 2282 ms Scrolling in this bugzilla page (zoomed 4 mouse clicks): 2457 ms 2475 ms 2467 ms 2514 ms 2447 ms Scrolling in fixedbackground.blogspot.com (default zoom): 4897 ms 4860 ms 4887 ms 5150 ms 4961 ms

I think those are pretty bad numbers. How does it compare to 3.6 for you?

Ok the funny thing is the scrolling on this bugzilla page is now in the range of 1300-1400 ms, with zoom, using my everyday profile. GMail now gives me 1800-2100 ms. This is with all the Acceleration options forced enabled (except DW) but with zero acceleration precisely because the i945GM chipset is blocklisted. =(

Even without acceleration I think those aren't good. What does 3.6 look like?

I am unable to start Firefox 3.6.13 successfully. A dialog box pops up with red words on yellow background: "<window id="main-window" ^ Where can I obtain ZIP builds of 3.6? What I just did was to extract the nonlocalized folder from the installer file using 7-Zip.

Try this ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/01/2011-01-12-03-mozilla-1.9.2/

Ok using the 3.6.14pre build I found there: GMail scrolling (same results with or w/o zoom): 1347 ms 1487 ms 1521 ms 1397 ms 1430 ms This bugzilla page: 927 ms 840 ms 796 ms 833 ms 795 ms http://fixedbackground.blogspot.com : 7341 ms 7443 ms 7313 ms 7661 ms 7290 ms

Ok, so 3.6 has reasonable numbers. We need to understand why we got so much worse on your system.

Shaun could you try this build https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ with HW ACC disabled and compare it with enabled, maybe this will be some hint

Results for enabled = results for disabled because my hardware is blocklisted. I've been using latest nightly for the past half year or more.

Thank you!

What platforms is this a problem with? The comments suggest Windows only but Henrik, you set the platform to all, what was that based on? I tried to reproduce this on my machine and couldn't see any problems, but then my machine is probably too fast.

Dave, perfectly reproducible with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112033217

Removing all rounded edges quickly to get rid of this problem is not solution without serious drawbacks. The design of the add-ons manager, and all in-page content, relies on edges and styling being consistent. Removing rounded edges from the manager means that widgets and the soft graphic style in the manager will be jarringly dissimilar to other elements on the page. All outward corners, from widgets to buttons to windows, are currently rounded. Change the main area to have sharp corners and not only is the manager inconsistently styled, but the main body of the manager appears sharp and unfinished. Outright removing these corners means a serious UI drawback for *all* users of the add-ons manager to benefit the few: those on Windows with enough add-ons to scroll. How many is that? According to AMO's metrics, that's about three rounding up. (http://blog.mozilla.com/data/2009/08/10/tracking-down-the-number-of-firefox-addon-users-with-hadoop/) With the addition of a few other styling bugs that are about to be nominated for blocking, even more add-ons will be visible in list view, meaning that even fewer users will ever encounter this problem. Before we rip out necessary styling for a quick fix, let's figure out how bad this problem is, and for how many. If anyone in Mountain View can reproduce this, let me know - I'm looking for people who are experiencing the problem so we can weigh how serious it is.

Even websites use border-radius and non-visible overflow. Check out Bug 625253 ! It seems that caused by the same regression.

Comment on attachment 503444 [details] [diff] [review] patch Based on the slowdown I see on my machine and the fact that the large majority of users have less than 10 extensions and so won't really be scrolling much I don't think it is worth losing the visual styling here.

Don't forget that CPU spikes when you move mouse on link too

(In reply to comment #35) > Outright removing these corners means a serious UI drawback This seems to slightly misuse the word "serious". The slow scrolling I get spoils most of my interactions with the add-ons manager, so I would think that's serious and warrants a workaround, assuming the underlying layout bug won't be fixed for Firefox 4. > for *all* users of > the add-ons manager to benefit the few: those on Windows with enough add-ons to > scroll. How many is that? According to AMO's metrics, that's about three > rounding up. > (http://blog.mozilla.com/data/2009/08/10/tracking-down-the-number-of-firefox-addon-users-with-hadoop/) Does this include users who have one or two "helper" extensions like a Skype toolbar installed and won't ever use the add-ons manager? And even ignoring this, wouldn't it make sense to assume that users with more add-ons will more often use the add-ons manager? Affecting only 10% of your users might still mean to make 9 out of 10 interactions with the add-ons manager unpleasant.

Dao: I think what Boriss was saying is that this is a platform problem in terms of their ability to scroll when there are CSS rounded corners, and "change the design so there are no more rounded corners" seems to be hiding the actual underlying problem instead of fixing it. Boriss: I agree with Dao that saying "this probably won't affect users" is a bit of a strange comment, based on the stats we have that indicate there are few users with a single add on, and the median number seems to be closer to 5 or so once people start playing with them. We expect that number to go up as restartless Add-ons take off. roc/tn: I'm moving this bug to your neck of the woods, since the scrolling performance regression is from your checkin. If the only feasible solution in the time of Firefox 4 is "remove the rounded corners," I'll make a frowny face, but guess that's what we'll have to do.

We are working on a fix for rounded-corner clipping. Let's hope it works.

So this is the same issue as the Youtube channel scrolling? Due to the rounded corners around the video preview images?

Yes.

Please retest now that bug 628745 has been fixed.

(In reply to comment #46) > Please retest now that bug 628745 has been fixed. I was considerably improved. http://hg.mozilla.org/mozilla-central/rev/8149e1a06476 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110125 Firefox/4.0b11pre ID:20110126103957 However, it slower than http://hg.mozilla.org/mozilla-central/rev/e3b1c75995ac Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104030354 (especially scroll with scroll arrow buttons) I tested * Smooth Scroll on * scroll arrow / mouse wheel

s/I was/It was/

Thats about what we expected.

not fixed here yet with 01/27 update, guess this will happen within the next days...

Nope, the fix is in the 01/27 nightly. What you are seeing is the improved speed.

Is it a joke???? Absolutely no change at all, as far as I am concerned.

I see no improvement, and CPU usage is 50% (whole core) while scrolling.

Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre ID:20110127030333 No improvement here either.

yeah I should have been more precise in my last comment Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre ... nothing changed here, and that's already what I meant, Minefield fully updated. So I'm not sure what I'm supposed to see...

Likewise, no improvement in the 20110127 official nightly. Is this actually going to be in the 01/28 Nightly instead? If not, I think it needs to be reopened since that's 4 confirmations of no improvement.

Fix for Bug 628745 is in the 20110127 build, but it seems unfortunately does not help the AOM scrolling.

I appreciate that the other bug was fixed, but given the user reports, I can't see how this can be marked "fixed" yet. Reopening.

This is definitely NOT fixed. If this is your idea of quality, I think I'll go to Chrome. Scrolling is a basic thing, if that doesn't work, what else doesn't work? Scrolling in the new AOM (which, by the way, is otherwise very nice) needs to improve. This should be a hard blocker, as it is a major and very visible performance issue. I'm running Win 7 x64 on Core 2 Quad with 8 GB ram and a GTX 280. I should think expecting smooth scrolling on such a system in not asking too much. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre

We are using rounded rect clips in FrameLayerBuilders on the items I would expect: scrollbars if they are there, backgrounds of items that intersect the corner, and the background/border of the main XUL scrollable element. Putting the border-radius and overflow hidden on the scrollable element itself instead of putting the scrollable element inside the element with border-radius and overflow hidden would speed this up a bit, if that is an option.

If some people didn't see it get better, there must be something else going on. On Windows 7 at least, only the bottom left and right corners are rounded. The only things that visually intersect those corners are the gradient background for the whole list, and the bottom scroll arrow. The gradient list background is drawn using a Fill to the rounded-rect path, using the linear gradient as the source. This operation might be super-slow in cairo I guess. Are the people who still see this slow getting D3D10 acceleration or not? The scrollbar background intersects the rounded corner even though that part is covered by the scroll arrow. Drawing those two themed elements could be quite slow since we draw to temporary surfaces and do alpha recovery. But then again, it's only two relatively small elements. Another possibility is that it's just the redrawing of the entire list every time we scroll that's slow. So if someone who sees the slowness can use DOM Inspector or Chromebug, try nuking the rounded borders on #view-port-container and see how much that actually helps. Alternatively, try replacing its linear-gradient background with "transparent" and see if that helps.

(In reply to comment #61) >Are the people who still see this slow getting D3D10 > acceleration or not? D3D10 is on here.

On for me as well.

I'm not sure that it's really hardware accel related at all. I experience basically the same performance with accel on or off on the following systems: Core 2 Duo 2.6 GHz, 4GB RAM, Win XP ... so D3D9 Core 2 Quad 2.4 GHz, 4GB RAM, Win7 64bit (32bit FF though)... so D3D10

Almost forgot, I also have it on a: Core Duo 1.3 GHz CULV laptop with 4GB RAM, Win7 64bit (32bit FF) With either D3D10 on or off, the scrolling makes the add-on manager near unusable on that laptop, which would lead me to think it's more CPU bound than graphics bound at all.

At least with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre I can see a great improvement. No sluggish scrolling on my MBP 2.53 GHz Cpre 2 Duo with 4GB RAM anymore. It doesn't matter if hardware acceleration is enabled or not.

(In reply to comment #61) > Another possibility is that it's just the redrawing of the entire list every > time we scroll that's slow. So if someone who sees the slowness can use DOM > Inspector or Chromebug, try nuking the rounded borders on #view-port-container > and see how much that actually helps. Alternatively, try replacing its > linear-gradient background with "transparent" and see if that helps. The slowdown only happens to me if the window is large enough. With a really small window the scrolling will be smooth and no spike in CPU usage. With a larger window the opposite is true. It is much improved over a pre-patch build though. Disabling the border-radius to 0 with DOM Inspector will make the scrolling much smoother with a large window, however I still get a CPU usage spike. Removing the border-radius makes the issue problem less apparent, judging by the CPU usage, it is nearly double of scrolling a normal window. I'm on OS X (10.6.6) FWIW, H/W accl on.

Interesting observation. I can confirm with Comment 67 that when I resize the window to show fewer rows of AddOns, the performance of scrolling does indeed improve. The more Addon entries shown in the window, the slower it gets.

yeah I mentioned it when I first reported this issue in another bug report: having hardware acceleration enabled doesn't change anything. Enabling "smooth scrolling" makes it a bit worse than it already is. ps: on side note, off topic here but I reported that a while ago and there's no change either, I do avoid hardware acceleration as it makes the resizing of Minefield lag.

(In reply to comment #69) > Interesting observation. I can confirm with Comment 67 that when I resize the > window to show fewer rows of AddOns, the performance of scrolling does indeed > improve. The more Addon entries shown in the window, the slower it gets. That makes sense, we have to paint more period with a larger window.

(In reply to comment #60) > Putting the border-radius and overflow hidden on the scrollable element itself > instead of putting the scrollable element inside the element with border-radius > and overflow hidden would speed this up a bit, if that is an option. That's not always the case, but it may be possible. It's not always the scrollbox that gets clipped by the rounded corners at the top. If there's an global notification (like addon compatibility is disabled), then that message will be above the scrollbox and have the rounded corners (see: http://grab.by/8D82). (In reply to comment #61) > On Windows 7 at least, only the bottom left and right corners are rounded. I assume you have a global notification showing (probably compatibility checking) - many people won't have any such notification shown, so the top corners will be rounded too. Note that this changed recently - bug 623207 removed the sorting bar. Before that, the top corners of the scrollbox were never rounded (the sorting bar got clipped instead). It'd be rather messy, but we might be able to make the scrollbox have the rounded corners at the top only when there's not a global notification shown. I've been playing around on my machine - I didn't think I had a lag, but removing the rounded corners does make the scrolling smoother and faster.

(In reply to comment #72) > Note that this changed recently - bug 623207 removed the sorting bar. Before > that, the top corners of the scrollbox were never rounded (the sorting bar got > clipped instead). Ah, I haven't updated since that landed. So that means another scrollbar button is involved.

Same here, independent from smooth or normal scrolling. Also noticed in the input-field of the "I am sad/happy"-Feedback-Addon (typing into the comment-field is quite painful since you "feel" how slow it is...) Mozilla/5.0 (Windows NT 5.1; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 (has also been on Beta 9)

What hardware do you see slow typing in the sad/happy input field? If you use a nightly build (or beta 11 when it comes out) is the situation improved?

It looks like the add ons managers makes good use of box shadow on Windows (based on a quick look at http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/winstripe/mozapps/extensions/extensions.css), that would help to explain why the scrolling is still slow.

box-shadow on buttons is especially slow because we have to do alpha recovery on the button to get the alpha mask to blur.

It's also very slow on my Firefox 4 beta 11... I just removed overflow:hidden; on #view-port-container with firebug, and it's smooth now, with no visual difference.

I can confirm that the change in comment 78 does make a HUGE difference. In clicking through all the various pages and options after the change, I don't notice any difference in appearance caused by that modification. Would this be something viable?

Not being familiar with the design of the addons manager I assumed the overflow hidden was needed for the visual design of the addons manager. Can someone familiar with the addons manager comment about the reason for that?

The comment about the overflow: hidden says: /* Needed to allow the radius to clip the inner content, see bug 595656 */ If that is no longer necessary then by all means lets get rid of it

It is still necessary if you want the border radius to clip the child content, I just would have thought it would be visually obvious without it.

The border-radius is to low to see a difference : http://2.speed-pictures.net/5ba46a1ad6720d1d95d3ffb0cd1409a9.png

Bug 595656 looks to be about seeing a difference.

Don't know if something has changed since that bug that would alleviate it, but I'm certainly no longer seeing the bottom radius border issue as shown before. Here's what the radius looks like currently with that "hidden" line both on and off. IF there's any difference, it's virtually imperceptible. The speed win here (massive) would hopefully override that.

Need to see it on all platforms to decide, Blair mentioned seeing a small difference on Linux.

remove overflow:hidden; on #view-port-container is work for me on WinXP without GAW. The scrolling become much more smooth after do so in add-ons manager.

FYI, I just finished testing this with the latest nightly on OSX 10.6 and Ubuntu. I can see no difference with the overflow:hidden commented out on any platform. Could this change be made in order to increase the performance (GREATLY) for final?

We can't expect a layout fix beyond bug 628745, can we?

I would like to profile this to confirm that box-shadow is the slowdown (assuming we keep overflow hidden and rounded corners). If the profile confirms that I don't know if much can be done for FF4, if it points to something else, then who knows. Also note that I can't profile this as Linux uses quite different styles in the add-on manager.

Can anyone else confirm a reason to keep overflow:hidden? I realize that perhaps conceptually it's necessary, but on the three platforms, I've been unable to find a case so far where the rendering of the AddOns page appears any different with it disabled. If I'm wrong, I'll gladly pipe-down. :)

(In reply to comment #91) > I would like to profile this to confirm that box-shadow is the slowdown > (assuming we keep overflow hidden and rounded corners). One option would be to cache box-shadow images somehow. (In reply to comment #92) > If I'm wrong, I'll gladly pipe-down. :) I think you're right.

(In reply to comment #93) > I think you're right. Try it yourself ! ;) (Or not if you want to make Firefox 4 addon manager a public laughingstock :D ) I'm surpised that nobody want to accept the idea that overflow is completely useless there...

Overflow isn't useless there. This is not question about perf improve in one page, this is question about showing how fast and modern firefox is. I also use overflow:hidden in one of my game-project and scrolling performance isn't quite good, especially with border-radius clipping. So i think keeping addons-manager design is important for improving firefox performance itself.

No one said that Overflow is a useless property in general. But, please, try it for yourself and show me where it makes a visible difference on this page. As mentioned before, if removing it somehow degrades the appearance, that's a different story. From what I can tell though, on all three platforms, having it there or not makes no difference at all. If the intent is, as you stated, to show how "fast and modern" Firefox is, then I don't believe needlessly including a property that dramatically slows the page down to the point of making scrolling look horrendous on lower end machines is the proper way to showcase this. Ideally, yes, the speed issues would be conquered first, making it possible to leave this enabled with no ill effects. Since that isn't the case yet though, it seems more than reasonable to remove the property (for the time being, until speed can be fixed) with the intent of putting it back in with a future release.

Tim, what about bug 595656, do you see that again with overflow:hidden removed?

I see bug 595656 on Linux and Windows if I concentrate on the bottom left corner. It's very subtle and not worth the trouble. (That's not to say that it wouldn't be nice if Gecko was just fast here.)

Robert, what I'm currently seeing on all platforms is shown by the second attachment in this bug (the screenshot I posted comparing on or off). Certainly doesn't look anywhere near as bad as the screenshots in bug 595656, at least to me.

I think it's time to take this workaround. Timothy, please chime in if a layout fix is imminent.

Comment on attachment 515887 [details] [diff] [review] front-end workaround (checked in) Blair, I know you were looking into this, we should take it if the visual impact is negligible.

I also want to add that "Get Add-ons" in Add-ons Manager loads extremely slow (about 5-7s). It's server issue or Firefox ? And any plans in improving this ?

Comment on attachment 515887 [details] [diff] [review] front-end workaround (checked in) (In reply to comment #100) > I think it's time to take this workaround. (In reply to comment #101) > Blair, I know you were looking into this, we should take it if the visual > impact is negligible. Yea, was thinking the same thing. It's the lesser of the three evils.

Comment on attachment 515887 [details] [diff] [review] front-end workaround (checked in) http://hg.mozilla.org/mozilla-central/rev/dd542a890eb7

So, FIXED?

was landed

This remains an open layout bug.

** 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

Although scrolling in the add-ons list is much better now (still not very fast, but a lot better than without the patch), scrolling in the "Get Add-Ons" list is still painfully slow and laggy. Also, switching to the Add-ons manager tab (no matter whether extensions, get add-ons, or plugins is shown) is a lot slower than switching to most webpages, including this bugzilla page and youtube. CPU also spikes when switching to the Add-ons Manager.

I suspect the problem here is that the page uses a spread radius on native-themed buttons. That is slow to render because we have to draw the button theme twice, recover alpha (the buttons are transparent at the corners), copy to the A8 mask, and then run a not-optimized spread algorithm over the alpha values. I suspect a profile here would show a lot of time in gfxBlur. Then adding/removing the border-radius or overflow:hidden would make scrolling a lot slower because it forces the window to be repainted completely for every scroll.

CPU spikes when you move mouse on link too, not on only scrolling

scrolling seems to be OK on 10b3 even in the "Get Add-Ons" page

This problem is more noticeable in Aurora 13.0a2 (2012-03-19) than Aurora 12.

Interesting, can you narrow down the regression using nightlies?

I can confirm this for Thunderbird 11.0 (stable release) win32. winchester cpu

(In reply to Ronald Tilby from comment #116) > This problem is more noticeable in Aurora 13.0a2 (2012-03-19) than Aurora 12. Is it just smooth scrolling being turned on by default?

(In reply to Jan from comment #118) > I can confirm this for Thunderbird 11.0 (stable release) win32. winchester > cpu Confirm what?

(In reply to Timothy Nikkel (:tn) from comment #120) > (In reply to Jan from comment #118) > > I can confirm this for Thunderbird 11.0 (stable release) win32. winchester > > cpu > > Confirm what? that it is slow, CPU usage spikes up

Guys. It was already said and I don't get why you ignore that. The real cause of the add-ons manager scrolling is BORDER-RADIUS of some elements. I can prove my point: 1. I've created a style, that makes all the items inside of the Add-ons manager's page occupy less space, so you can see more add-ons in the window of the same size than you normally would. http://userstyles.org/styles/55791/ergonomic-add-ons-manager You have to install this style (either by importing it to Stylish, or by putting the style's code to the userChrome.css file (you'll have to create it in ".../your_fx_profile/chrome/" folder, if you don't have one). 2. You'd better have a long list of the installed extensions (they may be even turned off - it doesn't matter, we just need more items to scroll). 3. Go to Add-ons manager and try to scroll the extensions page. You'll notice huge lags, especially if yo have smooth scrolling enabled (then it will be absolutely opposite to smooth). Remember that result for future comparison. 4. Install that style: http://userstyles.org/styles/63290/fix-add-ons-manager-lags-when-scrolling This style just removes all border-radius from any elements on the Add-ons manager's page. 5. Now try to scroll the list of your extensions and compare this result with the one in step 3: without border-radius scrolling is super-smooth and fast. Q.E.D.

Bug 716439 lets us accelerate scrolling inside an element with 'overflow' not 'visible' and 'border-radius', which will completely fix this bug.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #123) > Bug 716439 lets us accelerate scrolling inside an element with 'overflow' > not 'visible' and 'border-radius', which will completely fix this bug. Will this also make drawing of tabs during tab animations faster?

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #35) > Removing all rounded edges quickly to get rid of this problem is not > solution without serious drawbacks. > > The design of the add-ons manager, and all in-page content, relies on edges > and styling being consistent. Removing rounded edges from the manager means > that widgets and the soft graphic style in the manager will be jarringly > dissimilar to other elements on the page. All outward corners, from widgets > to buttons to windows, are currently rounded. Change the main area to have > sharp corners and not only is the manager inconsistently styled, but the > main body of the manager appears sharp and unfinished. > > Outright removing these corners means a serious UI drawback for *all* users > of the add-ons manager to benefit the few: those on Windows with enough > add-ons to scroll. How many is that? According to AMO's metrics, that's > about three rounding up. > (http://blog.mozilla.com/data/2009/08/10/tracking-down-the-number-of-firefox- > addon-users-with-hadoop/) With the addition of a few other styling bugs > that are about to be nominated for blocking, even more add-ons will be > visible in list view, meaning that even fewer users will ever encounter this > problem. > > Before we rip out necessary styling for a quick fix, let's figure out how > bad this problem is, and for how many. If anyone in Mountain View can > reproduce this, let me know - I'm looking for people who are experiencing > the problem so we can weigh how serious it is. 1 Whole Core of a Sandy Bridge System consumed in 2012 for a simple scrolling operation and MS Marrow finds this unproblematic ? ;)

(In reply to timbugzilla from comment #124) > Will this also make drawing of tabs during tab animations faster? No. The underlying bug here is fixed now that bug 716439 has landed.