16864 - Spinner & progressbar consume stunning CPU time (GTKfe/Linux)

Status: VERIFIED DUPLICATE of bug 13131

(Core :: XUL, defect, P3)

Description

[Adam D. Moss]

Overview Description: When the spinner and progress barber-shop pole are
spinning at the same time, ie. whilst fetching a page, excessive drawing occurs
and 50% of the CPU of a 6x86/233 is consumed with this task, additionally making
interaction sluggish.

Steps to Reproduce:
1) Load a page over a slow connection (or better yet, simultaneous multiple
pages over a slow connection in multiple browser windows).
2) Observe 'top' or CPU meter.
3) Observe response speed of interacting with UI components.
4) Having double-buffering disabled (or presumably enabling paint-flashing)
makes the presumed root cause more evident - painting of excessive area.

Actual Results: Highly excessive CPU utilization.

Expected Results: Very minimal CPU utilization.

Build Date & Platform Bug Found: Last observed with most
recent CVS build tried -- ~19th Oct.  First observed some
months ago.

Additional Builds and Platforms Tested On: None.

Additional Information: This is actually a lot better than
it used to be, thanks to the GTKfe fixes of Pavlov et al
a week or two ago, such that the repainted area now excludes
the main content area.  Still excessive and unpleasant,
however.

This may be pertinent?
http://x22.deja.com/=dnc/getdoc.xp?AN=519557529

Comment 1

[Peter Trudelle]

spinner == throbber?  BTW, I get an error clicking on the link above.

Comment 2

[Peter Trudelle]

reassigning to pavlov

Comment 3

[Matthew Tuck [:CodeMachine]]

This sounds like a dupe of bug #13131.

Comment 4

[Adam D. Moss]

Yes!  13131 is the same animal.  Sorry for dupping, 'throbber' was the key word
I neglected in searching.


*** This bug has been marked as a duplicate of 13131 ***

Comment 5

[Alan S. Jones]

verified dup of bug 13131 repainting everything between progressmeter and 
throbber