Last Comment Bug 623615 - Scrolling by mouse wheel lagged on Add-ons Manager. It is remarkable if enabled smooth scrolling
: Scrolling by mouse wheel lagged on Add-ons Manager. It is remarkable if enabl...
Status: RESOLVED FIXED
[softblocker][firefox 4 fix landed][a...
: perf, regression
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal with 16 votes (vote)
: mozilla15
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 625045 625104 626516 629017 633850 637659 642371 645516 (view as bug list)
Depends on: 628745 GPU-clipping-rounded
Blocks: 100951 slowui 595656 602892 628366
  Show dependency treegraph
 
Reported: 2011-01-06 08:29 PST by Alice0775 White
Modified: 2013-12-27 14:19 PST (History)
66 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.x+


Attachments
patch (4.17 KB, patch)
2011-01-13 02:31 PST, Dão Gottwald [:dao]
dtownsend: review-
Details | Diff | Review
Example of the current appearance. (144.69 KB, image/jpeg)
2011-02-09 16:54 PST, Tim Meader
no flags Details
front-end workaround (checked in) (2.57 KB, patch)
2011-03-01 05:04 PST, Dão Gottwald [:dao]
bmcbride: review+
dtownsend: approval2.0+
Details | Diff | Review

Description Alice0775 White 2011-01-06 08:29:52 PST
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
Comment 1 Henrik Skupin (:whimboo) 2011-01-06 11:22:56 PST
Could this be related to how the list entries are getting drawn, i.e. rounded borders, or any SVG related objects?
Comment 2 Henrik Skupin (:whimboo) 2011-01-07 00:51:42 PST

*** This bug has been marked as a duplicate of bug 623739 ***
Comment 3 Alice0775 White 2011-01-07 01:46:48 PST
U dont think dup,
No cpu spike.
Comment 4 Alice0775 White 2011-01-07 01:57:30 PST
s/U/I/
Comment 5 Alice0775 White 2011-01-07 02:37:27 PST
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
Comment 6 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2011-01-07 02:42:07 PST
Robert: This sounds like it could be a performance regression from bug 602892.
Comment 7 Alice0775 White 2011-01-07 04:35:41 PST
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
Comment 8 Timothy Nikkel (:tnikkel) 2011-01-07 12:47:01 PST
Yes bug 602892 was expected to cause this exact situation to slow down, it was a correctness fix so scrolling looked visually correct.
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-09 20:39:15 PST
If you just removed the almost invisible rounded corners from the addon manager panes, this problem (and others) would go away.
Comment 10 Alice0775 White 2011-01-09 20:49:31 PST
(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;
}
Comment 11 Alice0775 White 2011-01-09 20:52:57 PST
s/userChrome.css/userContent.css/
Comment 12 Ken 2011-01-10 01:07:25 PST
  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.
Comment 13 wamsaya 2011-01-12 07:37:04 PST
It has been happening to me for a quiet long time. Very annoying bug.
Comment 14 David Dahl :ddahl 2011-01-12 10:43:14 PST
*** Bug 625104 has been marked as a duplicate of this bug. ***
Comment 15 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-12 11:04:46 PST
Or just simply do a circle movements with your mouse in Add-ons Manager in Get add-ons tab.
Comment 16 Luke Iliffe (Harlequin99) 2011-01-12 11:47:54 PST
*** Bug 625045 has been marked as a duplicate of this bug. ***
Comment 17 Shaun 2011-01-12 17:48:47 PST
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.
Comment 18 Timothy Nikkel (:tnikkel) 2011-01-12 20:49:37 PST
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?
Comment 19 Shaun 2011-01-12 22:47:48 PST
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.
Comment 20 Timothy Nikkel (:tnikkel) 2011-01-12 22:50:30 PST
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)
Comment 21 Shaun 2011-01-12 23:12:57 PST
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
Comment 22 Timothy Nikkel (:tnikkel) 2011-01-12 23:14:49 PST
I think those are pretty bad numbers.

How does it compare to 3.6 for you?
Comment 23 Shaun 2011-01-12 23:29:11 PST
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. =(
Comment 24 Timothy Nikkel (:tnikkel) 2011-01-12 23:32:44 PST
Even without acceleration I think those aren't good. What does 3.6 look like?
Comment 25 Shaun 2011-01-12 23:48:15 PST
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.
Comment 27 Shaun 2011-01-13 00:09:51 PST
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
Comment 28 Timothy Nikkel (:tnikkel) 2011-01-13 00:57:40 PST
Ok, so 3.6 has reasonable numbers. We need to understand why we got so much worse on your system.
Comment 29 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-13 01:03:04 PST
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
Comment 30 Shaun 2011-01-13 01:36:28 PST
Results for enabled = results for disabled

because my hardware is blocklisted.

I've been using latest nightly for the past half year or more.
Comment 31 Dão Gottwald [:dao] 2011-01-13 02:31:44 PST
Created attachment 503444 [details] [diff] [review]
patch
Comment 32 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-13 02:45:46 PST
Thank you!
Comment 33 Dave Townsend [:mossop] 2011-01-13 10:47:39 PST
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.
Comment 34 Henrik Skupin (:whimboo) 2011-01-13 10:54:23 PST
Dave, perfectly reproducible with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112033217
Comment 35 Jennifer Morrow [:Boriss] (UX) 2011-01-13 11:00:52 PST
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.
Comment 36 Csaba Kozák [:WonderCsabo] 2011-01-13 11:07:31 PST
Even websites use border-radius and non-visible overflow. Check out Bug 625253 ! It seems that caused by the same regression.
Comment 37 Dave Townsend [:mossop] 2011-01-13 11:15:03 PST
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.
Comment 38 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-15 14:13:08 PST
Don't forget that CPU spikes when you move mouse on link too
Comment 39 Dão Gottwald [:dao] 2011-01-17 13:36:23 PST
(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.
Comment 40 Luke Iliffe (Harlequin99) 2011-01-17 14:21:51 PST
*** Bug 626364 has been marked as a duplicate of this bug. ***
Comment 41 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-17 21:18:47 PST
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.
Comment 42 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-17 21:20:44 PST
We are working on a fix for rounded-corner clipping. Let's hope it works.
Comment 43 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-17 21:21:41 PST
*** Bug 626516 has been marked as a duplicate of this bug. ***
Comment 44 Scott A. 2011-01-18 07:30:05 PST
So this is the same issue as the Youtube channel scrolling? Due to the rounded corners around the video preview images?
Comment 45 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-18 12:48:40 PST
Yes.
Comment 46 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-26 21:08:22 PST
Please retest now that bug 628745 has been fixed.
Comment 47 Alice0775 White 2011-01-26 22:12:19 PST
(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
Comment 48 Alice0775 White 2011-01-26 22:13:53 PST
s/I was/It was/
Comment 49 Timothy Nikkel (:tnikkel) 2011-01-26 22:25:49 PST
Thats about what we expected.
Comment 50 logos 2011-01-27 06:28:24 PST
not fixed here yet with 01/27 update, guess this will happen within the next days...
Comment 51 Timothy Nikkel (:tnikkel) 2011-01-27 09:12:37 PST
Nope, the fix is in the 01/27 nightly. What you are seeing is the improved speed.
Comment 52 wamsaya 2011-01-27 09:25:47 PST
Is it a joke???? Absolutely no change at all, as far as I am concerned.
Comment 53 Csaba Kozák [:WonderCsabo] 2011-01-27 09:35:02 PST
I see no improvement, and CPU usage is 50% (whole core) while scrolling.
Comment 54 Steve England [:stevee] 2011-01-27 10:22:47 PST
Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre ID:20110127030333

No improvement here either.
Comment 55 logos 2011-01-27 11:14:14 PST
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...
Comment 56 Tim Meader 2011-01-27 12:55:26 PST
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.
Comment 57 Csaba Kozák [:WonderCsabo] 2011-01-27 13:01:20 PST
Fix for Bug 628745 is in the 20110127 build, but it seems unfortunately does not help the AOM scrolling.
Comment 58 Tim Meader 2011-01-27 13:36:43 PST
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.
Comment 59 Asbjørn Riis-Knudsen 2011-01-27 13:41:48 PST
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
Comment 60 Timothy Nikkel (:tnikkel) 2011-01-27 13:45:15 PST
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.
Comment 61 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-27 14:52:22 PST
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.
Comment 62 Csaba Kozák [:WonderCsabo] 2011-01-27 15:03:01 PST
(In reply to comment #61)
>Are the people who still see this slow getting D3D10
> acceleration or not?

D3D10 is on here.
Comment 63 wamsaya 2011-01-27 15:12:00 PST
On for me as well.
Comment 64 Tim Meader 2011-01-27 15:14:22 PST
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
Comment 65 Tim Meader 2011-01-27 15:29:22 PST
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.
Comment 66 Henrik Skupin (:whimboo) 2011-01-27 15:36:54 PST
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.
Comment 67 d.a. 2011-01-27 15:49:46 PST
(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.
Comment 68 Henrik Skupin (:whimboo) 2011-01-27 15:52:27 PST
*** Bug 629017 has been marked as a duplicate of this bug. ***
Comment 69 Tim Meader 2011-01-27 15:54:31 PST
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.
Comment 70 logos 2011-01-27 15:57:55 PST
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.
Comment 71 Timothy Nikkel (:tnikkel) 2011-01-27 15:58:43 PST
(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.
Comment 72 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2011-01-27 17:07:25 PST
(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.
Comment 73 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-01-27 17:12:38 PST
(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.
Comment 74 erikernst2 2011-02-03 01:09:19 PST
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)
Comment 75 Timothy Nikkel (:tnikkel) 2011-02-03 10:57:24 PST
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?
Comment 76 Timothy Nikkel (:tnikkel) 2011-02-04 18:02:29 PST
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.
Comment 77 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-02-06 17:56:55 PST
box-shadow on buttons is especially slow because we have to do alpha recovery on the button to get the alpha mask to blur.
Comment 78 Guillaume Chau 2011-02-09 15:03:01 PST
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.
Comment 79 Tim Meader 2011-02-09 15:17:00 PST
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?
Comment 80 Timothy Nikkel (:tnikkel) 2011-02-09 15:27:49 PST
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?
Comment 81 Dave Townsend [:mossop] 2011-02-09 16:08:33 PST
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
Comment 82 Timothy Nikkel (:tnikkel) 2011-02-09 16:14:21 PST
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.
Comment 83 Guillaume Chau 2011-02-09 16:22:59 PST
The border-radius is to low to see a difference :
http://2.speed-pictures.net/5ba46a1ad6720d1d95d3ffb0cd1409a9.png
Comment 84 Timothy Nikkel (:tnikkel) 2011-02-09 16:26:59 PST
Bug 595656 looks to be about seeing a difference.
Comment 85 Tim Meader 2011-02-09 16:54:45 PST
Created attachment 511238 [details]
Example of the current appearance.

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.
Comment 86 Dave Townsend [:mossop] 2011-02-09 17:08:36 PST
Need to see it on all platforms to decide, Blair mentioned seeing a small difference on Linux.
Comment 87 Michael 2011-02-11 01:12:17 PST
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.
Comment 88 XtC4UaLL [:xtc4uall] 2011-02-13 13:49:13 PST
*** Bug 633850 has been marked as a duplicate of this bug. ***
Comment 89 Tim Meader 2011-02-14 17:55:42 PST
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?
Comment 90 Dão Gottwald [:dao] 2011-02-18 07:46:21 PST
We can't expect a layout fix beyond bug 628745, can we?
Comment 91 Timothy Nikkel (:tnikkel) 2011-02-18 11:43:56 PST
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.
Comment 92 Tim Meader 2011-02-18 11:50:45 PST
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. :)
Comment 93 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-02-18 16:33:27 PST
(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.
Comment 94 Guillaume Chau 2011-02-19 01:13:12 PST
(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...
Comment 95 Alex Shilov 2011-02-20 01:51:02 PST
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.
Comment 96 Tim Meader 2011-02-20 10:28:44 PST
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.
Comment 97 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-02-20 14:42:26 PST
Tim, what about bug 595656, do you see that again with overflow:hidden removed?
Comment 98 Dão Gottwald [:dao] 2011-02-20 14:58:44 PST
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.)
Comment 99 Tim Meader 2011-02-20 16:57:45 PST
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.
Comment 100 Dão Gottwald [:dao] 2011-03-01 05:04:36 PST
Created attachment 515887 [details] [diff] [review]
front-end workaround (checked in)

I think it's time to take this workaround. Timothy, please chime in if a layout fix is imminent.
Comment 101 Dave Townsend [:mossop] 2011-03-01 07:49:51 PST
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.
Comment 102 Virtual_ManPL [:Virtual] - (ni? me) 2011-03-01 09:25:48 PST
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 103 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2011-03-01 14:29:20 PST
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 104 XtC4UaLL [:xtc4uall] 2011-03-01 15:16:09 PST
*** Bug 637659 has been marked as a duplicate of this bug. ***
Comment 105 Dão Gottwald [:dao] 2011-03-02 01:05:01 PST
Comment on attachment 515887 [details] [diff] [review]
front-end workaround (checked in)

http://hg.mozilla.org/mozilla-central/rev/dd542a890eb7
Comment 106 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-02 11:58:19 PST
So, FIXED?
Comment 107 Andreas Gal :gal 2011-03-02 11:58:30 PST
was landed
Comment 108 Dão Gottwald [:dao] 2011-03-02 13:03:40 PST
This remains an open layout bug.
Comment 109 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-03 07:21:53 PST
** 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
Comment 110 Anton van Bohemen 2011-03-03 08:07:41 PST
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.
Comment 111 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-03-03 18:41:42 PST
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.
Comment 112 Virtual_ManPL [:Virtual] - (ni? me) 2011-03-03 23:37:28 PST
CPU spikes when you move mouse on link too, not on only scrolling
Comment 113 XtC4UaLL [:xtc4uall] 2011-03-17 18:45:05 PDT
*** Bug 642371 has been marked as a duplicate of this bug. ***
Comment 114 Dave Townsend [:mossop] 2011-09-04 16:57:06 PDT
*** Bug 645516 has been marked as a duplicate of this bug. ***
Comment 115 eyal gruss (eyaler) 2012-01-11 11:36:27 PST
scrolling seems to be OK on 10b3 even in the "Get Add-Ons" page
Comment 116 Ronald Tilby 2012-03-19 18:54:34 PDT
This problem is more noticeable in Aurora 13.0a2 (2012-03-19) than Aurora 12.
Comment 117 Timothy Nikkel (:tnikkel) 2012-03-20 00:35:35 PDT
Interesting, can you narrow down the regression using nightlies?
Comment 118 Jan [:Jan\] 2012-03-22 18:30:22 PDT
I can confirm this for Thunderbird 11.0 (stable release) win32. winchester cpu
Comment 119 Timothy Nikkel (:tnikkel) 2012-03-22 18:38:15 PDT
(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?
Comment 120 Timothy Nikkel (:tnikkel) 2012-03-22 18:38:33 PDT
(In reply to Jan from comment #118)
> I can confirm this for Thunderbird 11.0 (stable release) win32. winchester
> cpu

Confirm what?
Comment 121 Jan [:Jan\] 2012-03-23 14:22:22 PDT
(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
Comment 122 Sean Newman 2012-03-29 15:11:12 PDT
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.
Comment 123 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-29 16:02:16 PDT
Bug 716439 lets us accelerate scrolling inside an element with 'overflow' not 'visible' and 'border-radius', which will completely fix this bug.
Comment 124 timbugzilla 2012-03-30 04:05:11 PDT
(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?
Comment 125 CruNcher 2012-04-07 09:27:23 PDT
(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 ? ;)
Comment 126 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-05-04 03:14:58 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.