255812 - scroll bar in extension manager is very slow, uses 70-100% CPU

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Chris Beck]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

Using Firefox 0.9.3 in Slackware 10 + 2.6.7 + Gnome 2.6.2  and also in Win2k (up
to date with security patches and service packs) I find that the scroll bar on
the extension manager is _really_ slow and uses an excessive amount of CPU
power.  By really slow I mean that I drag it down and on a P4 2.6 with 512 megs
of ram it takes sveral seconds to move down a few millimeters.  This is with
between 20 & 30 extensions installed.

Reproducible: Always
Steps to Reproduce:
1.Install > 20 extensions (including Tabbed Browser Extensions, Adblock, and
All-In-One gestures)
2. Open extension manager
3.  Drag scroll bar, watch as CPU shoots up, scroll bar is very laggy

Actual Results:  
Scroll bar was really unresponsive

Expected Results:  
It should have been like lightening with 2 smaller lightenings on either side
going much faster.

Comment 1

[Ryan Polk (Quark)]

This is a fringe case, but is likely related to the Download Manager performance
issues.  I've heard it said somewhere that this is a general RDF problem.

Related download manager issue @ bug 211632

Comment 2

[Dimitrios]

This bug seems to be depended on bug 90198. The fixed backgound image is
probably causing this abysmally slow response on my machine (Geforce MX440,
P4-2.4MHz, Win2K). I'll investigate it more.
See also bug 227260.

Comment 3

[Ria Klaassen (not reading all bugmail)]

I have the same problems. Here is a screenshot:
http://img.photobucket.com/albums/v337/tamarix/taskmanager.jpg

The peaks of the diagram arise when my mouse is only in the Extension manager.
The flat 100% CPU usage is when I'm scrolling in the taskmanager (very, very
slowly).

I also think that the bug is related to bug 90198.    

Comment 4

[Mathieu Pellerin]

I think its a mixture of a non-opaque png background + the fixed background bug
that is making the whole thing slow ... I edited the default skin to use opaque
(read no imgs, no alpha transparency) and it worked like a charm, I think the
dev should switch to this solution until they fix other issues that are making
this bug show up...

you can vote for this on bug 255824

Comment 5

[Dimitrios]

I put my vote on Mathieu's bug. Also noting that Charamel theme doesn't suffer
from this bug. Assuming it doesn't use transparent pngs.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: change themes so that we can blit when scrolling

The key points here are:
 * don't use 'background-attachment: fixed'.  Our optimization for it should
check if there's actually a background image, but currently it doesn't.
 * Have a background color on things with 'overflow: auto'.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #6)
>  * don't use 'background-attachment: fixed'.  Our optimization for it should
> check if there's actually a background image, but currently it doesn't.

I filed bug 258793 on this.

Comment 8

[B A]

>I edited the default skin to use opaque
> (read no imgs, no alpha transparency) and it worked like a charm, 

Could you explain the process in more detail, please?

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 158481 [details] [diff] [review]
change themes so that we can blit when scrolling

sr+a=[e-mail]

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2004-09-27 22:20 -0700.
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-09-27 22:21 -0700.

Comment 11

[Steffen Wilberg]

So this is fixed in mozilla/toolkit/themes/winstripe.
Do we need to fix   mozilla/toolkit/themes/pinstripe (= Mac)
              and   mozilla/toolkit/themes/qute (= TB) as well?

Comment 12

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #11)
> So this is fixed in mozilla/toolkit/themes/winstripe.
> Do we need to fix   mozilla/toolkit/themes/pinstripe (= Mac)
>               and   mozilla/toolkit/themes/qute (= TB) as well?

What about custom themes? Do they need to do something as well?

Comment 13

[Ryan Polk (Quark)]

If a custom theme is slow, it's up to the themers to fix it.  If you know of any
themes that are slow, you should tell the author and show them this bug to make
it easier for them to know what to change.

Comment 14

[Peter van der Woude [:Peter6]]

*** Bug 261989 has been marked as a duplicate of this bug. ***

Comment 15

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #13)
> If a custom theme is slow, it's up to the themers to fix it.  If you know of any
> themes that are slow, you should tell the author and show them this bug to make
> it easier for them to know what to change.

Then I'll let the theme authors know.

Comment 16

[Dimitrios]

Some days ago, I mailed Kasteo about the Noia theme.

Comment 17

[Ria Klaassen (not reading all bugmail)]

Scrolling through the Extensions manager using the default theme and a lot of (=
more than 24) extensions installed, goes painfully slow with an extremely high
CPU-usage.

1. Click Tools > Extensions or go to
chrome://mozapps/content/extensions/extensions.xul?type=extensions
2. Scroll down using the wheel or the scrollbar.
3. See the high CPU usage in the Taskmanager and hear the ventilator making a
lot of noise.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050424
Firefox/1.0+