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?
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
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.
OK (I'm not sure that I'll have time to do it before the week-end though).
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.
Slow scrolling on pages with fixed elements: bug 201307 Slow scrolling on pages with fixed backgrounds: bug 90198
confirm this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030503 Mozilla Firebird/0.6
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
This appears to be duplicate of 124150. It is an issue because of the LARGE background image.
I am using Mozilla Firebird - Glendale release, and I am seeing the same issue.
http://texturizer.net/firebird/ Lock the menubar and scroll down _smoothly_. It's too slow.
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
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?
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
Works fine with latest RC builds in Linux. CPU usage is very less.
removing the URL, I changed my website design and no longer use PNG nor dixed positionning.
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.
(In reply to comment #20) > removing the URL, I changed my website design and no longer use PNG nor dixed > positionning. WFM then?
Summary: page scrolling extremy slow with smoothscrolling on. 100% CPU use → page scrolling extremely slow with smooth scrolling on. 100% CPU use
(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
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.
(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.
Bug 223724 comment 21 has a testcase and is OS: All, so maybe this bug is a dup of that.
Assignee: roc → nobody
Product: Mozilla Application Suite → Core
QA Contact: asa → general
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?
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.
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?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Scrolling quite sluggish (CPU usage is 100% too) when I turn smooth scrolling on. w7 x86 2gb ram a64 3200+ geforce 6800gs
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 → ---
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 .
Comment on attachment 610497 [details] proposed temporal solution. This isn't a patch.
(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"?
Matti, any idea what would be a good starting component for this? Or do we need a profile first?
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)
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: 9 years ago → 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.