310912 - High CPU usage for directional scrolling (using up/down arrow keys)

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[user_2_2_2]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051002 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051002 Firefox/1.6a1

when you scroll with directional keys in the about the "about:config" window
(and now this happens in "Bookmarks" sidebar as well), the CPU usage goes to 100%
(my computer is a 2.0GHz Pentium 4, downclocked to 1.2GHz)

Reproducible: Always

Steps to Reproduce:
1. open a new window or tab
2. type "about:config" in the address bar
3. click on a preference in the "about:config" window
4. scroll with the directional keys

for the Bookmarks sidebar problem
1. open the Bookmarks sidebar [CTRL-B] if you don't already have it open
2. create lots of bookmarks untill a scrollbar appears if you don't already have
that many
3. click the scrollbar on the sidebar
4. scroll with the direction keys
Actual Results:  
CPU usage goes to 100 or almost 100%

Expected Results:  
CPU usage should be less than 40%

Comment 1

[u63580]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051001
Firefox/1.4.1

WFM

Comment 2

[Aaron P]

I experience 100% CPU usage with slow vertical scrolling in about:config.

Firefox 20050908 (1.5b1) build
2Ghz P4
1GB RAM
Windows 2000 SP4

Comment 3

[Adam Guthrie]

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

Comment 4

[R.K.Aa.]

using 20051002 semonkey trunk, i found it extremely sluggish. (upgraded from
2005092405)
-Pages loding in new tabs block all scrolling in other tabs untill loaded.
-Load a simple page as todays bugs in bugzilla, and i can't scroll with
scrollwheel at all - nor by clicking in scrollbar, for several minutes.

I can, however, drag the thumb. CPU usage is unreasonably high during this all,
between 90% and 100% for extended periodes, allthough nothing seems to go on in
the browser at all.

Comment 5

[R.K.Aa.]

filing it as a separate bug since bug is resolved a a duplicate. 
The bug i see is new - later than sep. 24.

Comment 6

[Andrew Schultz]

This regressed between linux Mozilla trunk builds 2005032205 and 2005032305,
perhaps bug 167115.  Can't tell for sure without a profile or maybe a testcase.

Comment 7

[Jan Varga [:janv]]

(In reply to comment #6)
> This regressed between linux Mozilla trunk builds 2005032205 and 2005032305,
> perhaps bug 167115.  Can't tell for sure without a profile or maybe a testcase.

Yes, it's the fix for bug 167115. Thanks for the initial investigation.
I'll take a look at it.

Comment 8

[Jan Varga [:janv]]

The problem is that the treebody has transparent background by default.
Neil, Boris, is it ok to just add default background colors to themes?

Comment 9

[Boris Zbarsky [:bzbarsky]]

No idea; I've lost track of how our themes stuff works (not that I ever had much
track of it).

Comment 10

[Jan Varga [:janv]]

Attachment: patch

roc, does this make sense to you?

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No. This won't work in a situation like this:

<div style="background:red; position:relative;">
  <div style="position:absolute;>...</div>
  <tree/>
</div>

where the tree is on top of some other content but its parent has a solid
background.

The quick fix here (suitable for branch) is to give the tree body frame a solid
background in themes. The better fix is to use the view manager's
nsViewManager::CanScrollWithBitBlt method for this check, although you may find
that even with that, you need to set background colors to get it to work. You'll
have to make it public and test it carefully.

Comment 12

[[e-mail]]

(In reply to comment #8)
>Neil, Boris, is it ok to just add default background colors to themes?
How will that work with the -moz-appearance: treeview; code?

Comment 13

[[e-mail]]

(In reply to comment #11)
> No. This won't work in a situation like this:
> 
> <div style="background:red; position:relative;">
>   <div style="position:absolute;>...</div>
>   <tree/>
> </div>
If native themes only support solid tree backgrounds, then you can stop your
background check at the tree, since most of the time it will be solid. Someone
who deliberately makes the tree transparent deserves the perf hit.

Comment 14

[Jan Varga [:janv]]

This seems to be more complex, I suggest to back out the fix for bug 167115.
If you want to use a background image in trees use this CSS rule:

tree > treechildren {
  background-image: url("grain_08.jpg");
}

and it will work correctly w/o a perf hit

What do you think?

Comment 15

[Alfred Kayser]

Normal trees should have a defined background, at least 'inherited' from any
parent (or from the 'system colors') instead of 'transparent'. So, let's say
that someone defines an orange page with a xul tree in it, the default expected
behaviour for the tree is that the background is then also orange. Using inherit
instead of transparent will achieve this.

More complex is the case when the designer wants to use a background image for
the page. Must the tree inherit the image? But then the image is displaced
(re-positioned at 0,0 within the tree?). Is it allowed to scroll the background
image for the tree with the hor/vert scrolling of the tree contents?

I think we should make these choices explicit as follows:
* If the designer wants to use one background for the whole page, including the
tree, he should make the tree explicitly 'transparent' (so that the background
of the tree doesn't scroll with the tree content, but is fixed with the page).
* Default behaviour should be to inherit the background styling from the
(non-transparent) parent.
* One can use system styling by setting -moz-appearance: treeview (as in the
'native' themes)

Comment 16

[Wayne Mery (:wsmwk)]

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

Comment 17

[Wayne Mery (:wsmwk)]

Has this been partially fixed by some other bug?  I don't see the extreme cpu suggested earlier. For trunk FF 20061116 windows:

* scroll with mouse wheel tops out at 20-25% cpu
* using up/down with arrow keys and limiting range such that no scrolling occurs is ~2-5% cpu
* positioning slows and cpu increases when scrolling, with cpu at 35-50%

Comment 18

[Martijn Wargers (dead)]

I can still see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061120 Minefield/3.0a1

Comment 19

[Wayne Mery (:wsmwk)]

Martijn, what did you use to test - about:config, or bookmarks?

Comment 20

[Wayne Mery (:wsmwk)]

OK I see it using arrow keys Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

same high CPU when using up/down arrow of scroll bar - is this the same problem??

Comment 21

[Wayne Mery (:wsmwk)]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090611 Shiretoko/3.5pre (.NET CLR 3.5.30729)

cpu using scrol bar is same as using arrows 40-70%

Comment 22

[Jan Varga [:janv]]

I don't think anyone is going to work on this given the plan to remove the XUL "tree" widget (bug 1446335).