Closed
Bug 202718
Opened 22 years ago
Closed 8 years ago
page scrolling extremely slow with smooth scrolling on. 100% CPU use
Categories
(Core :: Graphics, defect, P2)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: pascalc, Unassigned)
References
Details
(Keywords: perf)
Attachments
(1 obsolete file)
build 2003041904 WinXP
(athlon 1700XP-768 MB Ram)
1 Set Mozilla with smoothscrolling ON
2 go to http://pascal.chevrel.free.fr/carnet/
3 scroll the page with the scrollwheel or page down key
expected result : usual fast scrolling
actual result : extremely slow scrolling and CPU use going 100%
The only unusual things in this page ares that it uses a position:fixed menu and
transparent PNG on some areas
Is scrolling actually slower --- does it actually take longer to get to the
bottom of the page by holding down a scrollbar arrow when smooth scrolling is
on? Or does it just FEEL slower?
Reporter | ||
Comment 2•22 years ago
|
||
It does not *seeem* to be slower, it IS slower, and as I indicated, there is a
100% CPU use while scrolling which is not normal. Just compare the scrolling
speed of this page with any other page.
Smooth scrolling is simply a lot more work and for a page like that, which
requires the entire page to be redrawn for every scroll operation, it's going to
use up all the CPU. There's nothing anyone can do about that.
There IS a problem, which is that if you hold down an arrow key for a while, and
then release it, we don't stop scrolling immediately. I'll investigate this.
Priority: -- → P3
Reporter | ||
Comment 4•22 years ago
|
||
Robert, I have no problem with smootscrolling on other web pages which I don't
consider as less complex as my page and which are usually much more graphics
intensive. I have added an alternate stylesheet (No PNG) which disables PNG
images and turns the fixed positionned menu into an absolutely positionned one.
With this simplified design, I still have 100% CPU use while scrolling.
Scrolling on any other page never takes all my CPU power. Note that my machine
isn't really a low-end system. I tried on a PIII-500/256MB RAM-Win98 and
scrolling on this page was extremely difficualt, I could see the page being
redrawn. Thanks for investigating.
Can you make a version of the page that doesn't use any fixed positioning or
fixed backgrounds, and post that? Any other simplifications you can do would
help too. Thanks.
Reporter | ||
Comment 6•22 years ago
|
||
OK (I'm not sure that I'll have time to do it before the week-end though).
Comment 7•22 years ago
|
||
Confirming the bug. Firebird also has the same problem. First noticed on this
site http://quadrone.org/phoenix. Note that both sites use transparent PNGs.
The issue could be related to this.
Comment 8•22 years ago
|
||
Slow scrolling on pages with fixed elements: bug 201307
Slow scrolling on pages with fixed backgrounds: bug 90198
Comment 9•22 years ago
|
||
confirm this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b)
Gecko/20030503 Mozilla Firebird/0.6
Comment 10•22 years ago
|
||
imho, it's not related to smoothscroll. i think it's the renderer itself. it
just takes much time to render it. the same problem happens when dragging the
scrollbar as well. it's indeed very noticable.
avih
Comment 11•22 years ago
|
||
This appears to be duplicate of 124150. It is an issue because of the LARGE
background image.
Comment 12•22 years ago
|
||
I am using Mozilla Firebird - Glendale release, and I am seeing the same issue.
Comment 13•22 years ago
|
||
this is either Bug 201307 or Bug 90198 I guess
Comment 14•21 years ago
|
||
http://texturizer.net/firebird/
Lock the menubar and scroll down _smoothly_.
It's too slow.
Comment 15•21 years ago
|
||
Smooth scrolling should give up smoothness, not speed, when bug 201307 or bug
90198 makes scrolling slow on a particular page.
It's supposed to ... and sometimes it does. There must be a bug.
Assignee: asa → roc+moz
Priority: P3 → P2
Comment 17•21 years ago
|
||
I think some additional problematic behaviour I've just found is related to this
bug. Smooth scrolling got EXTREMELY slow for me on some pages sometime after
the 0.6.1 milestone (like www.texturizer.net/firebird ) as well as this problem:
1. Load up www.texturizer.net/firebird
2. In the menu bar, select "Tools", then "Options"
3. Click and drag the options window all over the place very rapidly.
The result is very slow and choppy behaviour. Is this bug and the smooth
scrolling one just two sides of the same coin?
Comment 18•21 years ago
|
||
load http://www.euroflorist.com/floriss-akersgaten.oslo/
make the window so short the lower frame gets a scrollbar
then wheel-scroll like mad: CPU goes to 100% and scrolling is weirdly lagged
compared to which mousewheel movements are make
Now right-click in the lower frame and select "This Frame-> Show only this
frame". Then repeat the scrolling routine.
Result: Scrolling is extremly much faster. Couldn't make cpu usage go over 30%.
Testing on Linux, current trunk CVS
Comment 19•20 years ago
|
||
Works fine with latest RC builds in Linux. CPU usage is very less.
Reporter | ||
Comment 20•20 years ago
|
||
removing the URL, I changed my website design and no longer use PNG nor dixed
positionning.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 21•20 years ago
|
||
Don't know if this is the same problem, but I get 100% CPU on this page:
http://xbtt.sourceforge.net/client/
Note that 100% CPU and slow scrolling only occurs when you scroll down to the
start of the screen shots, which are transparent PNGs.
Comment 22•20 years ago
|
||
(In reply to comment #20)
> removing the URL, I changed my website design and no longer use PNG nor dixed
> positionning.
WFM then?
Updated•19 years ago
|
Summary: page scrolling extremy slow with smoothscrolling on. 100% CPU use → page scrolling extremely slow with smooth scrolling on. 100% CPU use
Comment 23•19 years ago
|
||
(In reply to comment #21)
> Don't know if this is the same problem, but I get 100% CPU on this page:
>
> http://xbtt.sourceforge.net/client/
I also see slow scrolling and 100% CPU usage on http://www.amdzone.com
Comment 24•19 years ago
|
||
The pages do scroll a tad slow, but I'm *not* seeing 100% CPU on my P4 3.4GHz w/512 MB of RAM & ATI Radeon X600 w/128 MB on the adapter.
Comment 25•19 years ago
|
||
(In reply to comment #24)
> The pages do scroll a tad slow, but I'm *not* seeing 100% CPU on my P4 3.4GHz
> w/512 MB of RAM & ATI Radeon X600 w/128 MB on the adapter.
>
Interesting. On my 2GHz PM laptop w/2GB of RAM and Mobility Radeon 9700 I see that scrolling this bugzilla page, Seamonkey takes about 13% of the CPU. Scrolling the sourceforge page takes 50%. Something has changed on the amdzone.com layout, it now takes about 50% for initial rendering, but only about 25% for scrolling. Still I notice the difference because the bursts of activity make the CPU temp rise noticably, and then the fan kicks in. Otherwise the machine is usually silent, so the sudden fan noise is pretty disturbing.
Comment 26•17 years ago
|
||
Bug 223724 comment 21 has a testcase and is OS: All, so maybe this bug is a dup of that.
Updated•16 years ago
|
Assignee: roc → nobody
Product: Mozilla Application Suite → Core
QA Contact: asa → general
Comment 27•16 years ago
|
||
This bug is making the recent regressions in scrolling performance for Firefox 3 much worse for users that have smooth scrolling turned on. Could we get it fixed for Firefox 3?
Flags: wanted1.9.0.x?
Updated•16 years ago
|
Flags: wanted1.9.1?
Comment 28•16 years ago
|
||
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x?
Comment 29•15 years ago
|
||
sorta WFM - I'm seeing 7-20% cpu, which a rare blip at 40-50%
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4pre) Gecko/20100406 Minefield/3.7a4pre
anyone else seeing this?
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Comment 30•15 years ago
|
||
Scrolling quite sluggish (CPU usage is 100% too) when I turn smooth scrolling on.
w7 x86 2gb ram a64 3200+ geforce 6800gs
Comment 31•15 years ago
|
||
The problem is that on some pages smooth scrolling is slow, and the smooth scrolling algorithm should give up smoothness, not speed, on these pages. See comment 16.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•13 years ago
|
Whiteboard: [Snappy]
Updated•13 years ago
|
Whiteboard: [Snappy]
Comment 32•13 years ago
|
||
it seems that hardware aceleration is broken with some drivers from ati vendors (and some nvidia as reported).
the easy fix is to deselect hardware acceleration .
Attachment #610497 -
Flags: review+
Comment 33•12 years ago
|
||
Comment on attachment 610497 [details]
proposed temporal solution.
This isn't a patch.
Attachment #610497 -
Attachment is obsolete: true
Attachment #610497 -
Flags: review+
Comment 34•9 years ago
|
||
(In reply to fernando from comment #32)
> Created attachment 610497 [details]
> proposed temporal solution.
>
> it seems that hardware aceleration is broken with some drivers from ati
> vendors (and some nvidia as reported).
>
> the easy fix is to deselect hardware acceleration .
Is this still the only recommended "fix"?
Comment 35•8 years ago
|
||
Matti, any idea what would be a good starting component for this?
Or do we need a profile first?
Flags: needinfo?(bugzilla)
Comment 36•8 years ago
|
||
based on
>the problem seems to be realted to hardware aceleration: -> with hardware acceleration enabled (options -> >general -
>hardware acceleration).
>when you disable this option, the problem goes away at least in ati cards!!!
But I doubt that this is still an issue after all the changes over time.
Can anyone still reproduce this bug ?
Component: General → Graphics
Flags: needinfo?(bugzilla) → needinfo?(mcastelluccio)
Updated•8 years ago
|
Flags: wanted1.9.1?
Comment 37•8 years ago
|
||
I don't have any info and all the URLs are dead or changed in the meantime.
Let's close the bug, if someone can reproduce, please reopen it.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 8 years ago
Flags: needinfo?(mcastelluccio)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•