Scrolling by mouse wheel lagged on Add-ons Manager. It is remarkable if enabled smooth scrolling

RESOLVED FIXED in mozilla15

Status

()

Core
Layout
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: Alice0775 White, Unassigned)

Tracking

(Blocks: 2 bugs, {perf, regression})

Trunk
mozilla15
perf, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 .x+)

Details

(Whiteboard: [softblocker][firefox 4 fix landed][approved-patches-landed])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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
(Reporter)

Updated

7 years ago
Summary: Scrolling by mouse wheel lagged. It is remarkable if enabled smooth scrolling → Scrolling by mouse wheel lagged on Add-ons Manager. It is remarkable if enabled smooth scrolling
Could this be related to how the list entries are getting drawn, i.e. rounded borders, or any SVG related objects?
Keywords: perf
OS: Windows XP → All
Hardware: x86 → All
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 623739
(Reporter)

Comment 3

7 years ago
U dont think dup,
No cpu spike.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

7 years ago
Status: REOPENED → NEW
(Reporter)

Comment 4

7 years ago
s/U/I/
(Reporter)

Comment 5

7 years ago
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.
(Reporter)

Comment 7

7 years ago
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
Blocks: 602892
Keywords: regression
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.
(Reporter)

Comment 10

7 years ago
(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;
}
(Reporter)

Comment 11

7 years ago
s/userChrome.css/userContent.css/

Comment 12

7 years ago
  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

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

Updated

7 years ago
Duplicate of this bug: 625104
Or just simply do a circle movements with your mouse in Add-ons Manager in Get add-ons tab.
Duplicate of this bug: 625045

Comment 17

7 years ago
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?

Comment 19

7 years ago
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)

Comment 21

7 years ago
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?

Comment 23

7 years ago
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?

Comment 25

7 years ago
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/

Comment 27

7 years ago
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

Comment 30

7 years ago
Results for enabled = results for disabled

because my hardware is blocklisted.

I've been using latest nightly for the past half year or more.
Created attachment 503444 [details] [diff] [review]
patch
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #503444 - Flags: review?(dtownsend)
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.
Attachment #503444 - Flags: review?(dtownsend) → review-

Updated

7 years ago
Assignee: dao → nobody
Status: ASSIGNED → NEW
Assignee: nobody → tnikkel
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.

Updated

6 years ago
blocking2.0: --- → ?
Duplicate of this bug: 626364
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.
Assignee: tnikkel → nobody
Component: Add-ons Manager → Layout
Product: Toolkit → Core
QA Contact: add-ons.manager → layout
We are working on a fix for rounded-corner clipping. Let's hope it works.
Assignee: nobody → tnikkel
Duplicate of this bug: 626516
blocking2.0: ? → final+
Whiteboard: [softblocker]
Blocks: 625253
Depends on: 626536
No longer depends on: 626536

Comment 44

6 years ago
So this is the same issue as the Youtube channel scrolling? Due to the rounded corners around the video preview images?
Yes.

Updated

6 years ago
Blocks: 628366
Please retest now that bug 628745 has been fixed.
Depends on: 628745
(Reporter)

Comment 47

6 years ago
(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
(Reporter)

Comment 48

6 years ago
s/I was/It was/
Thats about what we expected.
Status: NEW → RESOLVED
Last Resolved: 7 years ago6 years ago
Resolution: --- → FIXED

Comment 50

6 years ago
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.

Comment 52

6 years ago
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.

Comment 55

6 years ago
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

6 years ago
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.

Comment 58

6 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.

Comment 63

6 years ago
On for me as well.

Comment 64

6 years ago
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

6 years ago
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.

Comment 67

6 years ago
(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.
Duplicate of this bug: 629017

Comment 69

6 years ago
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

6 years ago
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.
(Reporter)

Updated

6 years ago
See Also: → bug 629587

Comment 74

6 years ago
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.

Comment 78

6 years ago
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

6 years ago
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.

Comment 83

6 years ago
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.

Comment 85

6 years ago
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.
Need to see it on all platforms to decide, Blair mentioned seeing a small difference on Linux.

Updated

6 years ago
Blocks: 599546

Comment 87

6 years ago
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.
Duplicate of this bug: 633850

Comment 89

6 years ago
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?

Updated

6 years ago
Blocks: 595656
We can't expect a layout fix beyond bug 628745, can we?
No longer blocks: 602892, 625253
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.
Blocks: 602892

Comment 92

6 years ago
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.

Comment 94

6 years ago
(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

6 years ago
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

6 years ago
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.)

Comment 99

6 years ago
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.
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.
Attachment #503444 - Attachment is obsolete: true
Attachment #515887 - Flags: review?(dtownsend)
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.
Attachment #515887 - Flags: review?(dtownsend) → review?(bmcbride)
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.
Attachment #515887 - Flags: review?(bmcbride) → review+

Updated

6 years ago
Attachment #515887 - Flags: approval2.0?
Attachment #515887 - Flags: approval2.0? → approval2.0+
Duplicate of this bug: 637659
Comment on attachment 515887 [details] [diff] [review]
front-end workaround (checked in)

http://hg.mozilla.org/mozilla-central/rev/dd542a890eb7
Attachment #515887 - Attachment description: front-end workaround → front-end workaround (checked in)
So, FIXED?

Comment 107

6 years ago
was landed
This remains an open layout bug.

Updated

6 years ago
Whiteboard: [softblocker] → [softblocker][firefox 4 fix landed]
** 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
blocking2.0: final+ → .x+

Comment 110

6 years ago
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.
Whiteboard: [softblocker][firefox 4 fix landed] → [softblocker][firefox 4 fix landed][approved-patches-landed]
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
Duplicate of this bug: 642371
Duplicate of this bug: 645516
Blocks: 100951
scrolling seems to be OK on 10b3 even in the "Get Add-Ons" page

Comment 116

5 years ago
This problem is more noticeable in Aurora 13.0a2 (2012-03-19) than Aurora 12.
Interesting, can you narrow down the regression using nightlies?

Comment 118

5 years ago
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?

Comment 121

5 years ago
(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

5 years ago
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.
Depends on: 716439

Comment 124

5 years ago
(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?
Assignee: tnikkel → nobody

Comment 125

5 years ago
(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.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Target Milestone: --- → mozilla15
You need to log in before you can comment on or make changes to this bug.