Closed
Bug 90198
Opened 23 years ago
Closed 14 years ago
Fixed background makes scrolling painfully slow
Categories
(Core :: Graphics, defect, P2)
Core
Graphics
Tracking
()
RESOLVED
FIXED
People
(Reporter: thorgal, Unassigned)
References
()
Details
(Keywords: perf, testcase)
Attachments
(2 files)
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010710 BuildID: 2001071008 Scrolling around on this page is really slow for me, much slower than on other, seemingly much more complicated ones. Reproducible: Always Steps to Reproduce: 1.Visit the URL 2.Scroll up and down. Actual Results: Slow scrolling Expected Results: Scrolling as usual.
Reporter | ||
Comment 1•23 years ago
|
||
I am not sure if I should file separate bug, but the page at http://www.mysql.org/listcats.php?menu=21&page_id=9 behaves in exactly the same way, e.g. it is really slow when scrolling, be it by scrollbar, be it by mouse-wheel. Linux/i686 - 2001071021
I have 2 very similar installs. Both debian potato and both use X3, but one is a 2.4.x kernel and the other a 2.2.x kernel. Hardwarewise one is a p3-600 and the other a p3-700. The 2.2.x/p3-700 is fine scrollingwise and the 2.4.x/p3-600 is not. It'll continue to scroll once I've released the key. Erm. Not sure what to make of this. (mozzy version is 2001072408 - but repeatable with 0.9.2)
Comment 3•23 years ago
|
||
The original URL doesn't seem to be valid any more. The one given by Miloslaw Smyk on 2001-07-12 appears to be valid. Scrolling seems fine for me : Duron800, Win98SE, 2001080114.
Reporter | ||
Comment 4•23 years ago
|
||
I've updated the original URL, because it's moved. Both it and the one I've attached later still scroll very slowly (Linux/i686 2001080106}. I think that it is caused by BODY tag definition that in both cases specifies background-attachment : fixed; which obviously is more gfx-heavy. Considering much slower gfx speed in Linux Mozilla, this is probably the reason you're not seeing it under Windows.
Comment 5•23 years ago
|
||
->layout
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen
Reporter | ||
Comment 6•23 years ago
|
||
BTW, I'm running Athlon@1.1GHz with 640MB of RAM and other pages scroll with 20-80Hz. But these are more like 2-4Hz.
*** Bug 100575 has been marked as a duplicate of this bug. ***
Changing summary to something more explicative :)
Summary: scrolling very slow → Slow scroll due to fixed background
Comment 10•23 years ago
|
||
some nice examples which shows the problem with fixed background are: http://www.webstandards.org/resources.html http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html (taken from bug 100575)
Summary: Slow scroll due to fixed background → scrolling very slow (fixed background)
Comment 11•23 years ago
|
||
Changing summary to something more explicative :)
Summary: scrolling very slow (fixed background) → Slow scroll due to fixed background
Comment 12•23 years ago
|
||
Changing summary to something more explicative :)
Summary: Slow scroll due to fixed background → scrolling very slow (fixed background)
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Comment 13•23 years ago
|
||
*** Bug 99764 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
now that the fix for bug 98252 was checked in, the page scrolls pretty fast for me. Is it still a problem for others?
Comment 15•23 years ago
|
||
*puts his hand up* Not sure how bad it was before but it scrolls now, but still slowly. Even with the small scrollspace I have I can see it. Not only that but it doesn't keep up with the keyrepeats either. in a bad way.
Reporter | ||
Comment 16•23 years ago
|
||
Yup, it's as slow as it was. Just checked with 2001092821.
Reporter | ||
Comment 17•23 years ago
|
||
Funny thing. I've just tested it on my laptop which is much slower than the desktop machine (i.e. Mobile Celeron 600 vs. Athlon 1.1 and ATI Rage Mobility 128 vs. Matrox G400), but here "slow" pages are scrolling quickly and some (but not all) things in Mozilla certainly seem to be snappier. Either something has changed in the last few days (doubtful), or there is some dependency on a version of kernel/xserver/whatever. As soon as I regain access to my desktop (two days?) I'll try to narrow it down.
Comment 18•23 years ago
|
||
mighty people of bugzilla, I suspect this is a dupe of 69169, but both bugs are assigned to Kevin. I've posted a comment in 69169, so let's wait and see.
Reporter | ||
Comment 19•23 years ago
|
||
Ok, I finally found time to conduct some more extensive testing (re: my comments two messages above). 1. Installing kernel 2.4.12 on the laptop did not make mozilla slower at all. 2. Also X is the same on both machines now - no change in speed. 3. What made the difference, was the depth of the screen: the laptop was using 1 6bpp, while desktop was 24/32bpp. Switching to 16bpp on the desktop made these slow pages fly (ok, they are still a bit slower than normal ones, but this is hardly noticeable). But there is more to it. I investigated my XF86Config-4 file and found that it contained settings to handle 32bpp mode properly on Matrox MGA400, namely the DefaultFBBpp and DefaultColorDepth had different values. It seems to be no longer necessary, so I set them both to 24 and voila, I have fast scrolling/redrawing Mozilla AND true color. At least for me, this bug is WFM.
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla1.0.1
Comment 20•23 years ago
|
||
*** Bug 69169 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 21•23 years ago
|
||
Ok, not so fast. After using the settings described in my 2001-11-05 comment for some time, I've to say that this is still an open problem, although now I understand it more clearly. First, this has nothing to do with Layout component, but rather with ImageLib and that's why I'm putting Stuart on a CC: list. The situation now is like follows: right after launch Mozilla is scrolling very fast, the window is refreshed quickly after switching from another desktop or deminimization. The URLs listed in this bug and in its dupes are behaving very fluently, just as I've described before). However, as I open more pages, tabs and windows, there comes a moment when everything graphics-intensive (like pages with fixed background or the mailer) gets very slow. This is not something gradual -- the problem either is or isn't there, depending on some threshold of opened pages). Also, with bigger screens, greater screendepths, active DRI and other videocard-ram consuming things the threshold is crossed quicker. And once the problem appears, there is no other way to get back to quick scrolling than restarting Mozilla (sporadically even that doesn't help, which I assume has something to do with other apps using gfx intensively). All this makes me think that this "threshold" is actually the point where offscreen pixmap allocations can no longer be made in gfx-card memory and some of them (or maybe even the backbuffer discussed in bug #95952, 2nd comment) end up being transferred over AGP repeatedly. This led me to think that the problem may disappear with introduction of less wasteful pixmap allocation (again, as described in bug #95952). This however was not the case - everything behaves more or less the same after the bug was fixed. Now, the problem may also be due to a bug in the xserver I'm using. I've XFree86 version: 4.1.0.1 and Matrox G400/32MB (running 1440x1080x24), while my laptop that never shows any problems in this area has the exact same version of XFree86, but gfx chip inside it is ATI Rage Mobility 128/8MB (running 1024x768x16). I (very cautiously) suggest that something may still be wrong with offscreen pixmap allocations and caching them for future reuse. Opinions?
Comment 22•23 years ago
|
||
This "slow scrolling" problem not only appears with fixed backgrounds, but with every page fixed elements appear. Try out scrolling the W3C-example of a fixed Menu: http://www.w3.org/Style/Examples/007/menus.html or the other way round - move or resize the frame on http://www.cross-browser.com/examples/drag3.html I've tested this pages in different browsers (IE6, Opera 6, Konqueror) on Linux and W2k - and they all work much smoother than mozilla 0.97. (OK :-) IE doesn't get the W3C-example) Greetings Thorsten
Comment 23•23 years ago
|
||
Thorsten, are you testing 0.9.7 on Linux or windows? If windows, you are likely seeing bug 98252, which was not fixed on windows till after 0.9.7 was released....
Comment 24•23 years ago
|
||
Boris, you're right. The extremly slow scrolling problem only occurs in the windows version (bug 98252). With Linux, mozilla isn't as fast/smooth as Opera or IE under Win, but it at leasr is much faster than the Win-version. And this can partially be blamed on the slower XServer. THX Thorsten
Comment 25•23 years ago
|
||
*** Bug 122423 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list to schedule bugs for post Mozilla1.0 milestones
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
Comment 27•23 years ago
|
||
*** Bug 126645 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
The last two dups (bug 122423 and bug 126645) were both reported against windows 2000. The one before that (bug 69169) was against Mac OS 8.5. Updating platform, OS to all.
OS: Linux → All
Hardware: PC → All
Comment 29•23 years ago
|
||
Built 2002032708, NT4 I've found another page that displays this : http://webnouveau.net/ This page used to be painfully slow with a night build from 10 days ago. Now it's a lot faster, and may look acceptable at first look, but if the "background-attachment: fixed; " attribute is removed from the CSS, the difference in scrolling speed is still huge.
Comment 30•23 years ago
|
||
Using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 The scrolling is still slow with fixed background images. One site I maintain is a good example: http://www.dnetc.org The CSS properties for the background are: background: #555 url("psy2.png") fixed; when 'fixed' is removed the speed and smoothness greatly improves. The machine last tested on 1.7Ghz P4, running Windows 2000 (w/ SP1) The same behavior was observed on a 500mhz Athlon running Windows ME, a 950mhz Athlon (tbird) running Windows 2000 (w/ SP2), and a 500mhz athlon running Linux 2.4.18 w/ X4.2 I'm pretty confident it's a bug with mozilla related to rendering fixed backgrounds, as other browsers such as IE and Opera can scroll alot smoother and more quickly on the same page, hardware/os.
Comment 31•23 years ago
|
||
Another slow scrolling page is http://www.rpgworldcomic.com/ . It doesn't have a fixed element, but a huge background-image with a "background-repeat: repeat-x; "-setting via CSS. The scrolling seems to be a bit faster, if the background-image is not on the screen on the lower parts of the page.
Reporter | ||
Comment 32•23 years ago
|
||
Andreas, this bug is about slow scrolling caused by fixed backgrounds. There is a lot of other slow scrolling bugs, including recently popular bug #102321. Please see if your comment belongs there. BTW, the page you mention scrolls quickly for me.
Comment 33•23 years ago
|
||
Status update: This page WFM on 2002050504 win32 on win2kpro.
Comment 34•22 years ago
|
||
Removing blocker status for bug 91351, as that bug already is blocked by bug 100951 (which this bug blocks). This still is not really fixed for me using 2002050408 trunk on Win2k on an Nvidia gForce 2 GTS. When I scroll down by pressing the cursor down key, CPU time constantly is at about 60 percent on my Athlon 1400.
No longer blocks: 91351
Comment 35•22 years ago
|
||
*** Bug 145034 has been marked as a duplicate of this bug. ***
Comment 36•22 years ago
|
||
Looks not so bad with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020531 What do you think ?
Comment 37•22 years ago
|
||
The following two URL's from this bug are slow scrolling using todays trunk build on WinXP on 750Mhz AMD machin http://www.flamenco-world.com/flamenco/autor.html http://www.go-mono.com/faq.html The other URL's are either no longer available or seem to be fixed.
Whiteboard: [TESTCASE]
Comment 38•22 years ago
|
||
*** Bug 154833 has been marked as a duplicate of this bug. ***
Comment 39•22 years ago
|
||
Scrolling looks normal using todays trunk and branch builds: 2002062808. I have WIN2K on 500Mhz intel and 128mb memory. May be this is specific to WINXP.
Comment 40•22 years ago
|
||
no, http://www.go-mono.com/faq.html is pretty slow here too (p3-500, Linux, nVidia TNT2)
Comment 41•22 years ago
|
||
Scroll performance suffers with this reduced test case
Comment 42•22 years ago
|
||
Same test with background-attachment: scroll
Comment 43•22 years ago
|
||
*** Bug 157824 has been marked as a duplicate of this bug. ***
Comment 44•22 years ago
|
||
*** Bug 159078 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
*** Bug 170030 has been marked as a duplicate of this bug. ***
Comment 46•22 years ago
|
||
-> Don. the reduced testcase in comment 41 is slow using 10/16/2002 cvs build on WinXP.
Assignee: kmcclusk → dcone
Status: ASSIGNED → NEW
Comment 47•22 years ago
|
||
*** Bug 169086 has been marked as a duplicate of this bug. ***
Comment 48•22 years ago
|
||
The following 4 bugs seem to be related (or duplicates): bug 90198 - scrolling very slow (fixed background) bug 172626 - Very slow scrolling unless the background is commented out bug 176150 - Fixed backgrounds cause horribly slow scrolling bug 184556 - style rule for fixed background causes lag when text scrolled
Comment 49•22 years ago
|
||
*** Bug 172626 has been marked as a duplicate of this bug. ***
Comment 50•22 years ago
|
||
*** Bug 176150 has been marked as a duplicate of this bug. ***
Comment 51•22 years ago
|
||
*** Bug 184556 has been marked as a duplicate of this bug. ***
Comment 52•22 years ago
|
||
Is this bug specific to Windows, or is it XP? Both testcases scroll OK for me on Mac OS X.
Comment 53•22 years ago
|
||
Simon, I can verify that this problem occurs in Linux. According to comment #30, this occurs in Windows 2000 and ME as well, not just XP.
Comment 54•22 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312 Browsing through the comments, I didn't see anyone mentioning screen resolution as a factor. http://www.esn-leiden.nl suffers from the same problem when I visit it at home, but only at a resolution of 1152*768. When I resize the window and it becomes smaller or when I visit it elsewhere with lower resolutions, everything is fine. The test case is horribly slow for me, even when I resize the window. Could it have to do with fixed backgrounds which are repeated? As far as I can see, the performance problem only kicks in when the fixed background is drawn more than once.
Comment 55•22 years ago
|
||
Even stranger: after resizing the site I mentioned in the previous comment and maximizing the window again, the performance problem has gone and everything performs smoothly. This doesn't happen with the testcase though. Sorry for the extra spam.
Comment 56•22 years ago
|
||
Same effect (slow scrolling with the mouse) can be shown at website: http://www.praxis-wiesbaden.de/start/sitemapfs.html (Sometimes some navigation around the site is needed to trigger effect.) Background image is fixed with external CSS stylesheet. Affected Browsers: NS7.02 final Moz.1.21 final Moz.1.3 final Affected OS: WinXpProSp1 german (all browsers) Knoppix/Linux (Moz. 1.21)
Scrolling with fixed backgrounds is fundamentally a lot more work than with static backgrounds. Can you find a browser that does it much faster than we do?
Comment 58•22 years ago
|
||
IE and Konqueror both seem to be faster on my machine running Debian unstable.
Comment 59•22 years ago
|
||
IE and Konqueror both handle fixed background images just fine with performance problems. The test cases attached to this bug don't scroll in most normal browsers (they're just one line), so they're not good examples: Check out this URL in IE vs. Mozilla (I'm personally using Phoenix) http://anomaly.hrunting.org/old.html On my Windows machine, Phoenix (a recent nightly) doesn't even render the background image. It just sits there sucking down 100% of the CPU. Not sure if that's fixed in new Mozilla trunk builds, but it was definitely a problem months ago when I originally looked up this bug (before, though, that background image rendered). The other URLs posted in this bug show the same problem.
Reporter | ||
Comment 60•22 years ago
|
||
Robert O'Callahan, please see comment #21. Mozilla sometimes can handle fixed elements/backgrounds quickly and I am pretty sure it depends on the way it (indirectly) handles video memory on gfx-board.
Comment 61•22 years ago
|
||
Mozilla can sometimes handle such pages with CSS-fixed background, but after some navigation the 'slow-down-effect' appears. This is everytime reproducable! It seems to me like a filled graphic buffer or a memory leak. Config: WinXpProSp1 de, Moz.1.3 20030312 en-us, iPIII 700 Mhz, 768 Mb Ram, Abit BX, Matrox Mill G400. Gustav
Comment 62•22 years ago
|
||
This is also incredibly visible with smooth scrolling when trying to scroll: http://ln.hixie.ch/?count=1000000 At high resolutions (1600x1200 for instance) it can take several seconds to scroll down just one page, as you watch it jerk through the frames of the scrolling animation like a slideshow. Reassigning to default owner. CCing background and scrolling people.
Assignee: dcone → other
Priority: P1 → --
QA Contact: petersen → ian
Summary: scrolling very slow (fixed background) → Fixed background makes scrolling painfully slow
Whiteboard: [TESTCASE]
Target Milestone: Future → ---
Comment 64•22 years ago
|
||
I just created a long text page with a fixed background pattern and measured time needed to scroll the page with a clockwatch using the down arrow key. I made 3 versions of the background, one with a PNG image with alpha transparency, one with the same PNG image without alpha transparency and one with this image in JPEG format : -with no-alpha PNG : 12 seconds -with JPEG : 12 seconds -with alpha PNG : 18 seconds I run the test 3 times and always got the same result (+- 0.5s). This is with build 2003042808 WinXP/768MB Ram, smoothscrolling on. I ran this test with IE6SP1 : 5 seconds I see no logical reason why the version with an alpha-blended PNG background should be slower since the PNG image is applied on the body and there is therefore no element to be displayed through the transparency.
Comment 65•22 years ago
|
||
>the PNG image is applied on the body and there is
>therefore no element to be displayed through the transparency.
Couldn't <html> have a background, too?
Comment 66•22 years ago
|
||
that's what I thought too, but if you put background-color:white on <body>, it doesn't change the timing.
Comment 67•22 years ago
|
||
<body background=....> is announced as 'deprecated' by W3C-Org. CSS should be used instead. But slowing down effect does _not_ depend on background is integrated by <body>tag or CSS style sheet.
Comment 68•22 years ago
|
||
Both the testcase and the working url:s scrolls smooooth for me. Build 2003042708. Can anyone re-test to confirm this?
Comment 69•22 years ago
|
||
Gustav, setting a background color on body when you use a PNG image with alpha transparency has the purpose to make sure that no calculation is done to calculate a transparency based on a background pattern set on the root element (html). My personal tests indicate that part of the problem in fixed background scrolling is sometimes related to Mozilla performance with PNG images which have an alpha channel. The same test with the same PNG image with background-attachment:scroll shows a big scrolling performance boost.
Comment 70•22 years ago
|
||
Testcase with a PNG background With background:scroll http://pascal.chevrel.free.fr/mozilla/bugzilla/pagelongueTPNG.htm With background:fixed http://pascal.chevrel.free.fr/mozilla/bugzilla/pagelongueTPNGfixed.htm
Comment 71•21 years ago
|
||
Another site with scrolling problems: http://www.bhmotorsports.com/ With smooth scroll turned on it is really painful to scroll. I tried saving the page on my computer and then deleted the "background-attachment: fixed" from the stylesheet. After that no more scrolling issues.
Comment 72•21 years ago
|
||
Another example: <http://www.macrabbit.com/cssedit/> This site is much slower to scroll in Camino than in Safari.
Comment 73•21 years ago
|
||
I tried to open URL in comment 62 in OS/2 trunk from last week. I saved it to disk with wget to check the size - about 550K - after what seemed like an eternity of 100% CPU load, giving up and closing the tab long before seeing the bottom of the page. In Linux of like build, it took over five minutes to get to the bottom of the page after hitting the end key. After 10 minutes I checked top, and found mozilla-bin CPU load continuing around 96%. Switching to CZ took over a minute. Switching back to browser took closer to 2 minutes. After 20 minutes, still 96% CPU load, so I X'd the tab, and mozilla-bin fell below 0.1%. Both systems are K6/2-5x0 with ET6100 PCI video.
Comment 74•21 years ago
|
||
I guess this bug really doesn't need more test cases, but I just ran into this side which is extremely slow, so I thought I would point it out. It's much slower than all other test cases in this bug (perhaps on par with the one in comment 59) http://weblogs.mozillazine.org/djst/
Comment 75•21 years ago
|
||
dear bug reports - please try again with a recent build. To me it seems that nearly all testcases are working fine. So it would be good to be able to concentrate on the remaining ones.
Comment 76•21 years ago
|
||
I've just retested every URL in this bug on Linux/x86/GTKfe on a 750MHz Athlon with GeForce2 on a June 24th Firebird build and all of the URLs that demonstrate fixed-background scrolling (rather than a 404 or something quite different) still perform somewhere between 'quite' and 'very' badly.
Comment 77•21 years ago
|
||
Okay - do you have a win32 system also handy for testing/comparing?
Comment 78•21 years ago
|
||
I was about to say 'no' but then I remembered that I do still have a win98 partition kicking around on this disk somewhere... I'll see if I can download the same MozFB build for mswindows.
Comment 79•21 years ago
|
||
(This'll take a while though; can't reboot until I've built this big fat Subversion repository...)
Comment 80•21 years ago
|
||
I've been trying to get my head around this myself... OS X g4/400mhz powerbook Camion 2003062704 Mozilla 2003062708-trunk (native scrollbars & not) it seems that most of the testcases here that have only a fixed background have no noticable slowdown. This includes: the attached testcase http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html http://www.esn-leiden.nl/ http://ln.hixie.ch/?count=1000000 However this page still is pretty bad... but i couldn't tell wht was fixed: http://anomaly.hrunting.org/old.html This is the only case I noticed where what looks to be a fixed background caused slownes (could also be the opacity+fixed bg causing the slowdown and not a simple case of a fixed bg): http://weblogs.mozillazine.org/djst/ HOWEVER, any cases of position:fixed /content/, such as that seen on: http://www.macrabbit.com/cssedit/ (mentioned in comment 72) http://www.w3.org/Style/ (mentioned in comment 22) ...still suffer extremely delayed scrolling and it seems to take 5-10 secs to scroll the w3c page.
Comment 81•21 years ago
|
||
Using 20030629 vacpp 1.4 branch for OS/2, I found most of the URL's anywhere from good to slightly glitchy on K6/2-550. The following were moderately glitchy or worse: comment 54, comment 59, comment 71, comment 72, comment 74 Because of comment 73 experience I didn't even try comment 62 again. The first URL in comment 22 is nearly hopeless. CPU pegs for a minute or so after clicking once in the scroll area, and repaint scrolled is horribly delayed. Multiple clicks made system unresponsive until given enough time for CPU to drop below 100%. Page is useless except under the most extreme duress.
Comment 82•21 years ago
|
||
http://anomaly.hrunting.org/old.html I know what's fixed because I wrote the page. If you look at it in IE, you'll see how it's supposed to be rendered properly (apparently, newer versions of Mozilla/Firebird don't render it the same [maybe correct, maybe not] way). At the top of life4_dom.css, @imported-ed stylesheet is this: HTML { background: #fff url(/imgs/museum.jpg) no-repeat bottom right; background-attachment: fixed; color: #000; margin: 0px; padding: 0px; width: auto; } Unfortunately, it looks like the 'background-color: transparent;' declaration in the BODY style is being ignored (or converted to white). In any case, that's what fixed, and yes, it's still unbearably slow (and a CPU hog) in Windows XP, Firebird 0.6.
Comment 83•21 years ago
|
||
Comment 81 was incomplete. Scrolling behavior on comment 59 was quite glitchy, but there's another problem on that page. The whole time there my CPU stays pegged. It drops when I switch tabs, but goes right back up when I return. My W98 machine has the same K6/2-550 and is every bit as glitchy on comment 59 using 1.4rc3.
Comment 84•21 years ago
|
||
Comment 59 URL apparently loads the CPU so heavily it disconnects Chatzilla, which won't auto reconnect until I wrest focus from that tab.
Comment 85•21 years ago
|
||
*** Bug 212066 has been marked as a duplicate of this bug. ***
Comment 86•21 years ago
|
||
*** Bug 215552 has been marked as a duplicate of this bug. ***
Comment 87•21 years ago
|
||
I seem to experience this problem when using a PNG with alpha transparency. When I have a normal PNG as my background image it scrolls fast but when there is a translucent one it scrolls slowly. If the translucent one is set as the main background and not just for certain parts of the page then it gets even worse.
Comment 88•21 years ago
|
||
Here's my end-user experience: With every Mozilla I've ever run (between when I started using Mozilla 100% of the time in late 2000 and the 2003101405 nightly I'm currently using), having any page with background-attachement: fixed; regardless of image type, size, or other options (JPG, PNG, GIF, etc), the cpu usage will peg at 100% with Mozilla-Bin (or Mozilla.exe on Windows) eating it up. On my Athlon XP 1700+ I use for work, there is a noticable delay in scrolling if the page has a fixed image (image loaded or not). This is under Linux/X11 under various video cards and drivers, and under Windows with various cards and drivers. It's all a matter of latency: on a text page, using the scroll wheel, the latecy of updates is such that even if I spin the moushe wheel a whole lot, the moment I stop, the page stops moving. However, with background attachement fixed images, I can easily enter scroll commands faster than they can be processed, leading to me watching the browser desperately scroll around long after I've stopped touching the mouse. In summary -- :-/
Comment 89•21 years ago
|
||
Here's a current Moz-focused page that does this. Totally pegs CPU. I have to X Moz or the tab the page is in to get the system useful again. 2003120507. http://texturizer.net/thunderbird/features.html
Comment 90•21 years ago
|
||
Hmm, I don't see a fixed background or unusual CPU usage for that page.
Comment 91•21 years ago
|
||
I right click the link in comment 89, then select the tab. 30 seconds elapse before the tab content even begins to paint, and CPU pegs for 82 seconds. Then I click the lower scrollbar space, and CPU pegs for 43 seconds. Hmmm, I just assumed from the presence of background images (several - http://texturizer.net/mozilla.org/css/colors.css) that they were fixed, and therefore this bug. Guess not. Wonder which bug I'm seeing? 2003120708 OS/2 on K6/2-550.
Comment 92•21 years ago
|
||
I don't know what bug you're seeing, but I'm pretty sure it's not this one. It sounds like it might be an OS/2-specific rendering problem, since I'm running on one of the platforms worst-affected by fixed-background's performance and I don't see a trace of a problem. Furthermore the page linked to from comment 89 has clearly been designed optimally for mozilla-base browser users and thus would have recieved prior testing on the 'tier one' platforms and unix/mac/win32 users would have kicked up a fuss if there were a problem. So it's very likely either OS/2 specific or your-system specific. I advise you to file a specific bug report for it.
Comment 93•21 years ago
|
||
Went trough 90% of the dupes and links on this bug and all of them, expect http://www.dutchbint.org/ are very very smooth!
Comment 94•21 years ago
|
||
I was designing a page and noticed how horrible scrolling was in Firebird 0.7 on a pretty new Macinosh Dual G$ with 1.5 GBs RAM. After working on it a while, I decided to see if any bugs have been filed, and here I am. I downloaded the latest nightly build of Mozilla – Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040205 – and sure enough, the scrolling is still unbearable. Safari and Internet Explorer for Macintosh both handle this page beautifully. Here's the page in question: http://kongming.net/sgz/biographies/wu/huanggai.html This bug has been in the database for years now, are there actually plans to fix it?
Comment 95•21 years ago
|
||
Yeah, I missed the spell check on Macintosh. And that's a Dual G4 533mHz.
Comment 96•21 years ago
|
||
On your page, scrolling is dominated by text drawing, because you're using justified text (which goes through a much slower text rendering path).
Comment 97•21 years ago
|
||
I have never seen justified text cause slowdowns in Firebird or Mozilla, and as I expected, removing the justification from my document made absolutely no difference. Even if it did, that would be another bug to report, because Mozilla would be the only browser which faced scrolling slowdowns when justified text was included in a page. I’d make a test case without the bells and whistles to demonstrate this, but the URL included in this document also serves as a perfect example without justified text or anything else like that. http://ln.hixie.ch/?count=1000000 That page also scrolls painfully slow. It is specifically fixed width positioning that causes this problem.
Comment 98•21 years ago
|
||
I wish bugzilla had an edit option to I could be lazy. Guess I'll just have to start proof reading. Not fixed width positioning, simply fixed positioning. Such as telling a background image to stay in place despite scrolling, or keeping an image in a certain location on the visible window despite document position (such as in the page I linked to above).
Comment 99•21 years ago
|
||
yeah, I'll vouch. Hixie's page (as linked in comment 97) hangs Mozilla solid the moment you touch the scrollbar (OS X 2004010305). I force-quit it after 3 to 4 minutes of spinning beach-ball.
Comment 100•21 years ago
|
||
All the pages scrolls very smooth on my AMD XP 1900+, Radeon 9700, Windows XP. Is this only Mac issue now?
Comment 101•21 years ago
|
||
> Is this only Mac issue now?
No. Still quite slow on my machine, though my machine is very slow by today's
standards: dual PII-300, 256MB RAM, Radeon 7200. Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7a) Gecko/20040128 Firebird/0.8.0+
Comment 102•21 years ago
|
||
The URL is kinda nasty-jerky (and the one in comment 94 is horrible) on my athlon-750 with GF-FX, too, Linux/x86.
Comment 103•21 years ago
|
||
most urls (hixie too) are really fast (2ghz) for me (firefox 0.8, win32), but this one still is *very* slow http://weblogs.mozillazine.org/djst/
Comment 104•21 years ago
|
||
*** Bug 224572 has been marked as a duplicate of this bug. ***
Comment 105•21 years ago
|
||
Okay, I was just at my friend’s place using what I believe was Firebird 0.7 stable on Windows XP. The site http://kongming.net/sgz/biographies/wu/huanggai.html worked basically flawlessly. The scrolling was perfectly smooth. Yet the problem persists in recent nightly builds of Firefox for OSX and badly so on a good dual processor G4 (I’m unable to use the most recent build because it crashes on launch). If there is any additional information I can get on this one that would be of use to anyone, please let me know.
Comment 106•20 years ago
|
||
Another very slow site: http://www.eclipse.org/proposals/eclipse-webtools/index.html
Comment 107•20 years ago
|
||
Of the last two sites posted, my browser works the opposite than those of the guys who posted. It seems to be an arbitrary bug. I'm using v 0.8 on a Dell 8200 with Windows XP.
Reporter | ||
Comment 108•20 years ago
|
||
Over the years that passed since I'd filed this bug I've observed that a lot depends on how much memory you have available on your graphics card, which in turn means that slowness is most probably caused by compositing operations (that are required to prepare pages with fixed background and/or elements) using pixmaps located in mainboard's RAM rather than gfx-board's RAM. For example, I had real trouble replicating this bug when using Radeon 9700 with 128MB. I've alluded to this before (see comment #21): is everything ok with Mozilla's handling of offscreen pixmaps?
Comment 109•20 years ago
|
||
I have a Radeon 9700 128MB (latest drivers) and my system is Dual Athlon XP 1700+ w/ 1024MB RAM and I still see the problem with the first attachment. It may also have to do with the size of the window (I run 1600x1200 normally, but the problem isn't as bad if I shrink the window).
Comment 110•20 years ago
|
||
*** Bug 244506 has been marked as a duplicate of this bug. ***
Comment 111•20 years ago
|
||
Just upgraded to 0.9 and am now experiencing this bug at this site (front page and any page with the planet background): http://www.bohemiandrive.com My user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 My old user-agent, with which I didn't experience the bug: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Have never had slowdown in IE 6 with the page. Did some testing with the same background image on a simple page, and the slowdown only happens when the background is both fixed and no-repeat: background-attachment: fixed; background-repeat: no-repeat; If the background is just one-or-the-other, the slowdown doesn't happen.
Comment 112•20 years ago
|
||
*** Bug 248632 has been marked as a duplicate of this bug. ***
Comment 113•20 years ago
|
||
(In reply to comment #111) > Just upgraded to 0.9 and am now experiencing this bug at this site (front page > and any page with the planet background): > > http://www.bohemiandrive.com The above site now uses a non-transparent background image, so the slowdown/100% CPU bug no longer occurs.
Comment 114•20 years ago
|
||
This definitely appears to be a graphics-card-related bug. I used to have an ATi Rage 128 Pro, and this bug appeared fully. I just upgraded to a ATi Radeon 9600 (256mb, AGP 4x) and this bug does not appear at all (or is at least so reduced that I can't notice it). Maybe this means that there is some inefficency in the scrolling, fixed position, or transparency code?
Comment 115•20 years ago
|
||
Scrolling is slow also on the following webpage: http://www.vpro.nl/programma/zomergasten/ I think this one is related to the other examples, as it also has a fixed background. By the way: I am using an ATi Radeon 8500 LE graphics card, and I do experience the slow-scrolling phenomenon. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040708 Firefox/0.9.2 (MOOX-AV).
Comment 116•20 years ago
|
||
*** Bug 261546 has been marked as a duplicate of this bug. ***
Comment 117•20 years ago
|
||
(In reply to comment #115) > Scrolling is slow also on the following webpage: > > http://www.vpro.nl/programma/zomergasten/ > > I think this one is related to the other examples, as it also has a fixed > background. > > By the way: I am using an ATi Radeon 8500 LE graphics card, and I do experience > the slow-scrolling phenomenon. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; > rv:1.7) Gecko/20040708 Firefox/0.9.2 (MOOX-AV). url given at the beginning of the bug scrolled slow while it was loading for about 5 sec then worked fine on scrolling, however #115's url was slow from the start and stayed slow using a Geforce 2 MX/400 PCI 64 MB sdram with 1.1 ghz p3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041019 Firefox/1.0
Comment 118•20 years ago
|
||
Yep I get slow scrolling here as well. http://www.vpro.nl/programma/zomergasten/ Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041019 Firefox/1.0 (MOOX M3) System Specs: Windows XP SP1a, GeForce 4 Ti 4200, 256 MBs of RDRAM, P4 2.4 gHz
Comment 119•20 years ago
|
||
*** Bug 266636 has been marked as a duplicate of this bug. ***
Comment 120•20 years ago
|
||
*** Bug 266694 has been marked as a duplicate of this bug. ***
Comment 121•20 years ago
|
||
Same problem here: http://www.monti-web.de/ I think the severity of this bug should be pushed up, its really annoying and seems to be more than two years old now...
Comment 122•20 years ago
|
||
www.bungie.net also exhibits the problem.
Comment 123•20 years ago
|
||
http://www.w3.org/Style/ isn't quite so bad as http://www.w3.org/Style/Examples/007/menus.html in current OS/2 trunk. The latter is still unacceptably slow. http://weblogs.mozillazine.org/djst/is still really bad. http://texturizer.net/thunderbird/features.html remains as described in comment 89, clearly the worst of the links included in this comment. None of the others I tried seem particularly bad any more, including the attached testcases and http://ln.hixie.ch/?count=1000000
Updated•20 years ago
|
Flags: blocking1.8a6?
Updated•20 years ago
|
Flags: blocking1.8a6? → blocking1.8a6-
Comment 124•20 years ago
|
||
Nominating as 1.1 blocker due to performance issue, and apparently significant number of users affected based on votes/cc list.
Flags: blocking-aviary1.1?
Comment 125•20 years ago
|
||
From my testing, I found that it seems to be a combination of image types (png, gif, bmp, jpg), image sizes (width and/or height not file size) and font size (px, em, pt, ex or Text Zoom). Image types and sizes: * gif: above a certain width and height with or without no-repeat scrolling becomes very slow. * png: if the image is repeated too much, scrolling becomes very slow. * bmp: no problems. * jpg: no problems. Font sizes: With background-attachment: fixed;, with or without an image, if the font size is too big scrolling becomes very slow. From my tests, on a fresh install of mozilla 1.8a6 with a new profile, scrolling becomes very slow with font size above these: * font-size: 17px; * font-size: 1em; * font-size: 13pt; * font-size: 2.4ex; My computer: * AMD 1.4Ghz * 768MB * Kyro II * Windows 2000 My tests can be found here: http://jove.prohosting.com/~l3ert/Fixed/
Comment 126•20 years ago
|
||
Dear bert, test3 and test5 are really slow here -> FireFox 1.0 on WinXP SP2 all others where ok. Thanks for testing!
Comment 127•20 years ago
|
||
test3 and test5 are the only ones slow for me too. But all the others tests can be made slow too by simply increasing the font size (either via CSS or directly with View -> Text Zoom). In my case, the font increase needed is minimal (from 100% to 110%).
Comment 128•20 years ago
|
||
(In reply to comment #103) > most urls (hixie too) are really fast (2ghz) for me (firefox 0.8, win32), but > this one still is *very* slow http://weblogs.mozillazine.org/djst/ While scrolling http://weblogs.mozillazine.org/djst/ works fine for me (cpu usage up to 80% though), scrolling pages from the archives (e.g. http://weblogs.mozillazine.org/djst/archives/007482.html) is terribly slow (cpu usage 100%). Both pages use the same (fixed) background image, however. As for berts tests: both test3 and test5 are a bit slower, but increasing the textzoom (up till 160%) doesn't make the other tests slower
Comment 129•20 years ago
|
||
(In reply to comment #128) > While scrolling http://weblogs.mozillazine.org/djst/ works fine for me (cpu > usage up to 80% though), scrolling pages from the archives (e.g. > http://weblogs.mozillazine.org/djst/archives/007482.html) is terribly slow (cpu > usage 100%). > Both pages use the same (fixed) background image, however. Both pages use the same background, but the archives have a alpha transparent background for the blog entries. I removed it from the main page because I couldn't stand the poor performance after switching to Linux, but I forgot to remove it from the other pages. I found that after switching to the nvidia drivers in Linux, the performance is improved, but not nearly as good as in Windows.
Comment 130•20 years ago
|
||
*** Bug 285960 has been marked as a duplicate of this bug. ***
Comment 131•20 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050313 Firefox/1.0+ win2ksp4,axp2400,nvidia gf4 (v71.84 drivers),1024x768x32@100Hz (note I use the ad-blocking userContent.css stuff from http://www.mozilla.org/support/firefox/adblock to get rid of any scrolling problems because of ads) Are people on windows 2000/xp still seeing this bug? I've been through all the urls posted and all the testcases from http://jove.prohosting.com/~l3ert/Fixed/ and it's only tests 5 & 12 are giving me minor slowdown. the other tests run fine. from a trawl of previously posted comments there's one or two web pages that still give me a little slowdown - http://www.bhmotorsports.com/ but the other examples are fine for me now - http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html - http://www.w3.org/Style/Examples/007/menus.html - http://anomaly.hrunting.org/old.html - http://ln.hixie.ch/?count=1000000 - http://kongming.net/sgz/biographies/wu/huanggai.html
Comment 132•20 years ago
|
||
(In reply to comment #131) > Are people on windows 2000/xp still seeing this bug? I've been through all the > urls posted and all the testcases from http://jove.prohosting.com/~l3ert/Fixed/ > and it's only tests 5 & 12 are giving me minor slowdown. the other tests run fine. In Windows 2K/XP, it might improve very much by fix of bug284716. But in it etc. Mac, it is very heavy.
Comment 133•20 years ago
|
||
(In reply to comment #128) > While scrolling http://weblogs.mozillazine.org/djst/ works fine for me (cpu > usage up to 80% though) Indeed, the main page is okay, but the comment pages (for instance: http://weblogs.mozillazine.org/mt/comment.cgi?entry_id=7722) are still very slow. I have done some recent testing, using build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050218 Firefox/1.0+ (MOOX M2). I am using an Ati Radeon 8600LE with Catalyst 4.6 drivers (certainly not the latest, but changing drivers has never seemed to make a difference for this particular problem). Some pages that were slow before seem to work fine now: http://ln.hixie.ch/?count=1000000 http://www.w3.org/Style/ http://www.w3.org/Style/Examples/007/menus.html http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html http://kongming.net/sgz/biographies/wu/huanggai.html However, a few pages still suffer from slow scrolling: http://www.vpro.nl/programma/zomergasten/ (very noticable) http://www.eclipse.org/proposals/eclipse-webtools/index.html (slight delay) http://weblogs.mozillazine.org/djst/archives/007482.html (terribly slow) The first also appears to be slow in IE, the others do not. (I haven't experienced any slowdowns for the other example pages mentioned above, but I suspect that a lot of them have been altered since they were listed as an example in this bug-thread.) The testcases at http://jove.prohosting.com/~l3ert/Fixed/ are okay, except for tests 3 and 5. Increasing the font size doesn't seem to matter here.
Comment 134•20 years ago
|
||
*** Bug 282415 has been marked as a duplicate of this bug. ***
Comment 135•20 years ago
|
||
I installed Mozilla 1.7.7 and scrolling is greatly improved (still not as smooth as on IE or Opera). After installing 1.7.7 I had to install an extension uninstaller [http://mozmonkey.com/extuninstaller/] in order to remove the undoclosetab extension [http://extensionroom.mozdev.org/more-info/undoclosetab] because it made tab impossible to close (either via the X or by midle-cliking them). Unfortunately, the extension uninstaller API didn’t install because of a script error so I had to uninstall undoclosetab manually [http://kb.mozillazine.org/Firefox_:_FAQs_:_Uninstall_Extensions]. After having uninstalled undoclosetab I reinstalled it. After that I tried several test cases concerning the slow scroll bug and noticed the improvement. I don't know if it was 1.7.7 that caused the improvement or if it was undoclosetab that somehow caused the problem in previous versions. Still the bug (if it is a bug anyway) is not fully resolved for me but the improvement is notable.
Comment 136•20 years ago
|
||
I just realized that what I wrote about undoclosetab and extension uninstaller doesn’t make much sense since I previously tested the bug on a clean install of mozilla 1.8a6 [https://bugzilla.mozilla.org/show_bug.cgi?id=90198#c125]. So it's probably 1.7.7 (also tried 1.8b and it gives similar results to 1.7.7).
Comment 137•20 years ago
|
||
Here is another page that is VERY slow on scroll ( more with keyboard than mouse ): http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1 with evil binary Nvidia GeForce2 64 mb, AMD 1.4Ghz
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 138•19 years ago
|
||
*** Bug 305446 has been marked as a duplicate of this bug. ***
Comment 139•19 years ago
|
||
*** Bug 297610 has been marked as a duplicate of this bug. ***
Comment 140•19 years ago
|
||
*** Bug 310975 has been marked as a duplicate of this bug. ***
Comment 141•19 years ago
|
||
Unfortunately I have to confirm this rather old bug as I experienced same problem using my current: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.1) Gecko/20060226 Debian/1.5.dfsg+1.5.0.1-3 Firefox/1.5.0.1 and also crosschecking with newest (using new profile!): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060308 Firefox/1.6a1 Testcase on http://jove.prohosting.com/~l3ert/Fixed/test5.html scrolls VERY slow with both. Using Opera or Konqueror it nearly scrolls at the speed of light :-(
Comment 142•19 years ago
|
||
(In reply to comment #125) [...] > * gif: above a certain width and height with or without no-repeat scrolling > becomes very slow. > * png: if the image is repeated too much, scrolling becomes very slow. > * bmp: no problems. > * jpg: no problems. I used some 1px thin repeat-x png before and it wasnt fun. A width of 4000px and no repeat was faster, but still not smooth. And with a (1px thin) repeat-x jpg its perfect. The image format really does make a difference. Completely weird if you ask me.
Comment 143•19 years ago
|
||
(In reply to comment #142) > The image format really does make a difference. Completely weird if you ask me. Is the real issue images with transparency vs. those without?
Updated•18 years ago
|
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Comment 144•18 years ago
|
||
mhsurfer comment #141: > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060308 Firefox/1.6a1 > > Testcase on http://jove.prohosting.com/~l3ert/Fixed/test5.html scrolls VERY > slow with both. Using Opera or Konqueror it nearly scrolls at the speed of > light :-( WFM http://jove.prohosting.com/~l3ert/Fixed/test3.html http://jove.prohosting.com/~l3ert/Fixed/test5.html of the 8-10 other links mentioned in the bug that I tested, all WFM. modest machine 3.2G P4 trunk seamonkey and firefox is there any link that still gives someone trouble with trunk builds?
Comment 145•18 years ago
|
||
I checked all the links from this bug report (not from duplicates) in Firefox nightly 20060607 for Linux and these two pages still scroll slowly: http://kongming.net/sgz/biographies/wu/huanggai.html http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css They both work just fine in Konqueror 3.5.3.
Comment 146•18 years ago
|
||
(In reply to comment #145) > I checked all the links from this bug report (not from duplicates) in Firefox > nightly 20060607 for Linux and these two pages still scroll slowly: > http://kongming.net/sgz/biographies/wu/huanggai.html > http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css News from the linux world :) If all windows stuff here is fixed, perhaps this bug should be changed to meta morphed to linux or the 3 blocking bugs (244506 244862 271952) moved to meta bug 100951 or 201307. otherwise, people may keep commenting here about windows, even though it no longer applies to windows. If nothing else, you might mentioned these URLS in one of the blocking bugs (bug 244862?) or create a new bug so they don't get lost in this massive bug.
Comment 147•18 years ago
|
||
Not going to block 1.8.1 for this bug.
Flags: blocking1.8.1? → blocking1.8.1-
Comment 148•18 years ago
|
||
*** Bug 341304 has been marked as a duplicate of this bug. ***
Comment 149•18 years ago
|
||
http://stegmann-w.de/ <- scrolling on that page is very slow. Anybody an idea why this happens? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060625 BonEcho/2.0a3 ID:2006062503 It's much faster in Opera 9 Looks like it's caused by the fixed background ?!
Comment 150•18 years ago
|
||
(In reply to comment #149) > http://stegmann-w.de/ <- scrolling on that page is very slow. This page is noticeably slow to scroll for me, also. I'm not sure why people are saying this no longer affects Windows? P4 2.8 GHz w/ Matrox P650 graphics card. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060625 BonEcho/2.0a3 ID:2006062503
Comment 151•18 years ago
|
||
The following example is even worse: http://www.debianhowto.de/doku.php/de:howtos:sarge:exim4_vexim2_courier_mailman Oh and btw: is there any bug about that flickering, when I'm scrolling?
Comment 152•18 years ago
|
||
Disabling background image definitely solves the problem (adblocked image and scrolling is smooth).
Comment 153•18 years ago
|
||
*** Bug 345768 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Flags: blocking1.9a1? → blocking1.9?
Comment 154•18 years ago
|
||
Another page for testing, I get up to 100% cpu on that page: http://www.gj-igb.de/ Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060813 BonEcho/2.0b1 ID:2006081305
Flags: blocking1.9? → blocking1.9-
Comment 155•18 years ago
|
||
Another really good example is http://www.fppdesign.com.au/ I get this Bug in FF 2.0.0.3 and 3.0a3 !
Comment 156•18 years ago
|
||
http://www.beaver6813.com/temp/design/ - The DIV background image is fixed... lags as you scroll down :( Only affects PC Firefox as far as i can tell :/
Comment 157•17 years ago
|
||
Re: Sam <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=90198#c156">(comment #156)</a> your testcase at http://www.beaver6813.com/temp/design/ worked fine for me (Firefox 2.0.0.3 on Linux) - that is the central column scrolled smoothly and as fast as you'd expect -- until I started randomly clicking bits of the furniture. Suddenly the scrolling of the test-test-test central column became incredibly slow and jerky. I closed the tab, reopened it, still slow and jerky. However! After restarting Firefox altogether, the testcase document scrolls perfectly once again... until I selected part of the 'test-test' text - scrolling immediately reverted to the very slow jerky behaviour.
Comment 158•17 years ago
|
||
Well i've found a work around.. but its certainly not ideal, for the DIV with the fixed background you MUST give it a height for it to not be jerky, trust me, i tried for hours with no success: height:auto; = jerkiness height:800px; for example gives no jerkiness So it basically means if you want to have a DIV with a fixed background image that div must have a height.. or else... Because of this on places like my blog where i know roughly what the height will be i've used: height:3500px !important; height:100%; Firefox doesn't support 100% and auto doesn't work right so its my only option :( (Of course correct me if im wrong, i'd always loved to know if theres a better workaround)
Comment 159•17 years ago
|
||
Just for comparison, the previous testcase posted is here: http://www.beaver6813.com/temp/design/ Testcase with the background NOT jerky: http://www.beaver6813.com/temp/design2/content.php
Comment 160•17 years ago
|
||
There's an ongoing discussion in the Gentoo Forums about this, titled "why does firefox suck on gentoo.". This issue is happening in Linux as well. Every Windows machine I've encountered does not have this problem. However, there are some Linux machines that simply do not, for whatever reason: http://forums.gentoo.org/viewtopic-t-536596-highlight-firefox+suck.html The page in question is a wordpress theme test site, which also has a static background + lots of alpha tranparency: http://themes.wordpress.net/testrun/?wptheme=701 Things to rule out: * Pango (makes no difference turning it on/off) * "Smooth" Scrolling (makes no difference) * Building from source as opposed to binary * Also happens with Firefox 3.0 alpha builds
Comment 161•17 years ago
|
||
(In reply to comment #160) > The page in question is a wordpress theme test site, which also has a static > background + lots of alpha tranparency: > > http://themes.wordpress.net/testrun/?wptheme=701 WFM, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070528 Minefield/3.0a5pre. The bug seems to be fixed due to the checkin in bug 343430.
Comment 162•17 years ago
|
||
I deeply apologize for the spam and the last pointless speculation. The wordpress page in comment #160 scrolls also in older builds flawlessly, thus no relation to bug 343430.
Comment 163•17 years ago
|
||
I believe this bug only happens in Linux (or at least is worst in Linux). I have a dual boot Pc and pages scrolls fine in Windows, but in Linux the same pages scrolls very slowly. And there is one more thing, the same problem happens when the page has div with (semi-)transparent PNG in backgroung.
Comment 164•17 years ago
|
||
(In reply to comment #163) > I believe this bug only happens in Linux (or at least is worst in Linux). I > have a dual boot Pc and pages scrolls fine in Windows, but in Linux the same > pages scrolls very slowly. This is reported at https://bugzilla.mozilla.org/show_bug.cgi?id=69020
Comment 165•17 years ago
|
||
I have this problem in Ubuntu 6.10 using Firefox 2.0.0.5. I first noticed it on the engadget.com web site. I'm dual booting Ubuntu and XP on a ThinkPad T60 and have no problems with Firefox in XP. However, I recently tried Swiftweasel, Epiphany, and Opera, in Ubuntu, to see if that solved the problem and it did not. Perhaps that indicates that the problem goes beyond Firefox itself?
Comment 166•17 years ago
|
||
Just for the record, I'm also using a ThinkPad T60 but with an Ubuntu 7.0.4 and FF 2.0.0.6. I have no problem at all with the engadget.com web site.
Comment 167•17 years ago
|
||
I didn't try Epiphany. In Opera everything seems right to me. Swiftweasel has the same problem (which is expected, as it is an optimized Firefox). I still believe it is a Firefox's bug. And people reported the same problem with other distributions, which indicates that it is not only a Ubuntu's problem. The problem is clearly in the relation between Firefox and Linux.
Comment 168•17 years ago
|
||
But then what explains that I do have the same problem with Opera? Presumably it makes sense that the problem also exists with Epiphany, because it's based on the Gecko engine (right?). I don't know how all this stuff works, I just know what's happening on my system. I did the update to Ubuntu's version of 2.0.0.6 today and it did not solve the problem for me.
Comment 169•17 years ago
|
||
I had an interesting experience upgrading to Feisty and both not having the slow scrolling problem and being able to reproduce it. First of all, I tried upgrading to Feisty when it first came out and keeping my home parition (but otherwise a clean install), after that I still had the slow scrolling problem. This time I upgraded to Feisty, with a totally clean install and reformatted home partition. Right away, even without the fglrx driver, the slow scrolling problem went away. Although in this configuration, there was a slight lag with scrolling still continuing for a second after I stopped (but it was very usable). Then I installed the Ubuntu version of fglrx 8.34.8 and also did not have the slow scrolling problem and no lag, although over certain images it will just barely hesitate for a second (almost not noticeable). However, as soon as I installed Adobe Flash the slow scrolling problem came back. I installed Flash when I went to a site in Firefox that needed it and Firefox prompted me that I needed the plugin. I let Firefox do the install. So I used my partition images I had made and reverted to my clean install of Feisty and my home paritition. This time I installed Flash first (also through Firefox), before installing fglrx. Then I installed fglrx and do not have the slow scrolling problem. So far (a couple days now) this has remained true.
Comment 170•17 years ago
|
||
Another example of extremely slow scrolling with linux/firefox-2.0.0.6 http://derstandard.at/?url=/?ressort=Linuxx or one of the linked newsitems http://derstandard.at/?url=/?id=3014390 scrolling makes firefox/xorg-X11 eat Dualcores :-( does not happen with windowsXP/firefox-2.0.0.6
Comment 171•17 years ago
|
||
For those of you who don't see this: The slowness is most noticeable when scrolling by page or more: use PageUp/PageDown, Ctrl-Home, Ctrl-End, or click in the scroll bar gutter. Scrolling by keyboard arrow, arrow button, or mouse wheel, doesn't show the problem. Note I have smooth-scroll turned off. When it's on, it's still slow, but you can see it repaint a few times so feels a little faster. I see this regularly on Windows Firefox 1.5, Linux Seamonkey 1.1.3, Linux Firefox 1.5 and 2.0.0.4.
Comment 172•17 years ago
|
||
> I see this regularly on Windows Firefox 1.5, Linux Seamonkey 1.1.3, Linux > Firefox 1.5 and 2.0.0.4. All of these have known security bugs, and Firefox 1.5 doesn't get security updates anymore. Please update to Firefox 2.0.0.8 and Seamonkey 1.1.5. And these versions only receive security updates. If you want to find out what's going on in active development, download a trunk nightly: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Or wait for the Firefox 3 Beta, which should be out in a couple of weeks.
Comment 174•17 years ago
|
||
Still present in firefox 2.0.0.8, ubuntu gutsy. see this webpage!!! http://www.oakparkfoundation.org/ I have both nvidia and ati products. both hardware with either opensource and proprietary drivers act in this way. so the problem should not be caused by drivers
Comment 175•17 years ago
|
||
(In reply to comment #174) > Still present in firefox 2.0.0.8, ubuntu gutsy. > see this webpage!!! > http://www.oakparkfoundation.org/ > > I have both nvidia and ati products. both hardware with either opensource and > proprietary drivers act in this way. so the problem should not be caused by > drivers > The situation in firefox3 alpha9pre is a lot better. Although the bug is still there but it appears in less websites than in firefox2. For example http://www.oakparkfoundation.org/ works for me but the bug still appears in some other sites also with an increased Xorg-server memory usage. http://meyerweb.com/eric/css/edge/complexspiral/demo.html works pretty fine as well.
Comment 176•17 years ago
|
||
Yes, the situation has improved with firefox 3 alpha9pre, I can confirm. but only for some sites for example these sites still do not work: http://jove.prohosting.com/~l3ert/Fixed/test5.html http://themes.wordpress.net/testrun/
Comment 177•17 years ago
|
||
Please be sure when you link to the wordpress themes site you link to http://themes.wordpress.net/testrun/?wptheme=701 and not http://themes.wordpress.net/testrun/ as users without the "cookie" set to the appropriate theme will likely get the default "Kubrick" theme which doesn't have the issue. The theme in question is one with a static background+alpha level transparencies not the indigo blue esthetically pleasing theme.
Comment 178•17 years ago
|
||
As of Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120900 Minefield/3.0b2pre This is still a major problem. This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html when scrolled the blockquotes displaying code lag majorly, with potentially seizure inducing choppiness. The text scrolls fine, it is just the blockquotes which sort of jump out of the page when scrolled. While the seizure part may be exaggerated, it does kind of hurt to look at it. It is worth nothing when the fixed is taken off the background, the problem does not exist at all. Occurs with smooth scrolling or not.
Comment 179•17 years ago
|
||
(In reply to comment #178) > As of Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120900 > Minefield/3.0b2pre This is still a major problem. > > This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html Confirming choppiness almost to complete unresponsiveness on that page. UA: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Comment 180•17 years ago
|
||
http://www.cyberpresse.ca/ is scrolling well for me in Firefox 2.0.0.11, but scrolls very slowly with 3.0b1. This is a very high profile newspaper site in Quebec.
This is *probably* a gfx issue over raw painting speed. Renominating based on regression reports.
Assignee: roc → nobody
Component: Layout: View Rendering → GFX
Flags: blocking1.9- → blocking1.9?
QA Contact: ian → general
Comment 182•17 years ago
|
||
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007121107 Minefield/3.0b2pre ID:2007121107 See some choppiness here as well - once the whole page is scrolled scrolling up/down is fine.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Comment 183•17 years ago
|
||
I've noticed in Debian that I have no scrolling issues with the Mesa driver, but I do with Fglrx. This is with 2.0.0.8, Debian Testing, an ATI mobility x1400, and FGLRX 8.40.4.
Assignee: nobody → vladimir
Comment 184•17 years ago
|
||
(In reply to comment #178) > This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html when Confirmed on Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008012204 Minefield/3.0b3pre. I've made a sysprof profile which shows that 95% of the time is spent on the X server (fedora 8's version with the binary nvidia driver v169.04). Now, who's the fault? I tend to think that gecko should be choosing the requests it does from the underlying graphics system and try to not tax said system too much. Of course such is easier said than done :-) and there is obviously the possibility that X and/or the driver are at fault here.
Comment 185•17 years ago
|
||
(In reply to comment #178) > This page here, http://oops.opsat.net/doc/gtk/gtkwindow-hello-world.html when Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11. Scrolling the page on Windows yields about 25-50% CPU, and lots of Window redraws (so much in fact its difficult to read the page unless the page is not scrolling). Note, this is probably different than the examples previously mentioned, where as they (on Windows) do not exhibit the same "painfully slow scrolling" as its Linux counterpart. However, comment #178 suggests a page that even in Windows is painfully slow. Perhaps all of this is a more fundamental/core/Gecko related and not OS specific?
Comment 186•17 years ago
|
||
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2 Page in comment #178 is still really bad. I also get the same jittering/slow scrolling effect while viewing mails at gmail.com . Opera and konqueror are much smoother on these pages.
We're not going to block on this -- we can't fix fixed background issues without Compositor, and things are better enough at this point.
Flags: wanted1.9+
Flags: blocking1.9-
Flags: blocking1.9+
Comment 189•17 years ago
|
||
Is this going to be fixed? It makes Firefox 3 unusable for me. FF2 works fine though. This really needs to be fixed.
I commited a fix in the last few days that should help some pages on Windows. We have a separate fix that affects gmail scrolling on all platforms, it hasn't landed yet. It won't help when you have gmail chat windows open, though.
Comment 191•16 years ago
|
||
(In reply to comment #182) > See some choppiness here as well - once the whole page is scrolled scrolling > up/down is fine. Right after I launch Mozilla, scrolling is facile and even, but it seems to become erratic, especially when everything is graphics-intensive (like pages with fixed background or the mailer). As stated by others, "This is not something gradual -- the problem either is or isn't there, depending on some threshold of opened pages." I'm running Safari on the same pages well [Apple MacBook Pro w dual core processing and Mozilla 2.0.0.13 Firefox.]
Comment 192•16 years ago
|
||
Another slow scrolling page: http://www.csseleven.com/ Strangely, it only scrolls slowly for me when the window width is just larger than the row of face pictures (when the window width is between about 950px and 1300px). If I reduce the width, or make it much larger, scrolling is fine.
Comment 193•16 years ago
|
||
Another example: http://ajaxian.com/ The problem still exists in FF 3.0b5!
Comment 194•16 years ago
|
||
I do not see this behavior on Firefox 3.0 Beta 5. I'm on XP SP3, 4GB RAM(3.4 visible to the OS), 600GB RAID0 for my C:, 8800GT(512MB) PCIe Video, and an Intel Core2Quad Q6600(4x 2.4ghz cores) all held together by an Intel D975XBX2.
Comment 195•16 years ago
|
||
Sorry I forgot to write, I use Linux (Kubuntu 8.04, 64-bit) and have this system: - Intel Core2Duo E8400 (on an MSI P7N Platinum) - 4 GB RAM - nVidia 8800 GTS 512 PS: I am not using the Kubuntu Firefox, I installed it by myself
Comment 196•16 years ago
|
||
The new beta seems to work better: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Comment 197•16 years ago
|
||
This issue shows much in Win32 Vista and XP. Complaints at MozillaZine has increased about the issue. http://forums.mozillazine.org/viewtopic.php?t=653791 Users report crippling scroll performance with multiple sites with fixed backgrounds. My machine also experiences this phenomenon with fixed background scrolling. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050706 Minefield/3.0pre ID:2008050706 Examples: http://sga.gatech.edu/ http://www.gameswelt.de/ http://www.fm-zagorje.org/ http://www.cssmagazine.it/
Comment 198•16 years ago
|
||
I can confirm slow scrolling perfomance on Linux/Ubuntu with http://ajaxian.com/ and other sites, but http://www.cssmagazine.it/ is the worst site of all I ever tried with Fx3. Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9pre) Gecko/2008050707 Minefield/3.0pre ID:2008050707
Comment 199•16 years ago
|
||
This bug has over 50 different example URL's (+ a testcase) where this bug can be seen. I think that should be enough not to post more "i see this here as well" comments.
Comment 200•16 years ago
|
||
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050706 Minefield/3.0pre on Windows XP Pro SP2 with a clean Firefox Profile. Hardware: DELL LATITUDE D505. 1) cssmagazine.it - I can reproduce the problem using both auto-scrolling than smooth-scrolling. 2) ajaxan.com - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling. 3) fm-zagorje.org - I CANNOT reproduce the problem using both auto-scrolling than smooth-scrolling. 4) gameswelt.de - I can reproduce the problem using both auto-scrolling than smooth-scrolling. 5) sga.gatech.edu - I can reproduce the problem using both auto-scrolling than smooth-scrolling. 6) csseleven.com - I can reproduce the problem using both auto-scrolling than smooth-scrolling. 7) gtkwindow-hello-world.html - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling. 8) .cyberpresse.ca - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling. 9) mono-project.com - I CANNOT reproduce the problem using both auto-scrolling than smooth-scrolling. 10) oakparkfoundation.org - I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling. 11) praxis-wiesbaden.de/start/sitemapfs.html- I can reproduce the problem using smooth-scrolling BUT NOT using auto-scrolling. I noticed Firefox behaves different using only the mouse-wheel than dragging the scroll-bar (more "power consuming")
Comment 201•16 years ago
|
||
(In reply to comment #199) > This bug has over 50 different example URL's (+ a testcase) where this bug can > be seen. I think that should be enough not to post more "i see this here as > well" comments. > But lots of those example URL's are no more valid or does exist no more (especially the old ones). Better stick with recent URL's as per https://bugzilla.mozilla.org/show_bug.cgi?id=90198#c199
Comment 202•16 years ago
|
||
Is scrolling part of PGO instrumentation? Perhaps if it was added, compiler could make things somewhat better, like it did with javascript.
Comment 204•16 years ago
|
||
418948 seems to be a duplicate of this bug... I've noticed that this bug also whenever "background-attachment: fixed;" appears in a CSS... With FF3RC1 it has becomen a serious bug... framerate on my computer (Intel Centrino core 2 duo, 2 Gb of ram) has decreased to something around 4 FPS The page where I noticed the most significant CPU usage is on my site: http://www.stogame.net/wiki
Comment 205•16 years ago
|
||
@jose #199: When it's fixed, it's enough. This is a serious bug and a regression from ff2. No better way to say that than 205 comments of "me too".
Comment 207•16 years ago
|
||
The worst offending site for me is ign.com, by far. The page is almost unusable when viewed with Firefox 3 running on Windows Vista. Around the internet, editing the usercontent.css is frequently suggested, but it made no difference to me. Turning smooth scroll on/off also makes no difference, nor did uninstalling/reinstalling flash. That's also problematic--some embedded flash videos load very slowly or not at all. Flash aside, the scroll is absolutely a critical bug to fix. Performance is MUCH worse than in either the current IE or the previous Firefox.
Comment 208•16 years ago
|
||
@Roberto Ramirez WORKSFORME: ign.com runs perfectly normals and smooth over here. Firefox 3 with Windows Vista.
Reporter | ||
Comment 209•16 years ago
|
||
Years ago (comment #21) I wrote that I suspected this bug was caused by offscreen pixmap allocation used by compositing operations required by pages with fixed elements/backgrounds. With NVIDIA Linux driver it is possible to force these pixmaps to video memory and presto, all testcases scroll very smoothly. Force them to system memory and they are dog-slow again. Respective commands are: nvidia-settings -a InitialPixmapPlacement=2 and nvidia-settings -a InitialPixmapPlacement=1 (documented here: http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/src/libXNVCtrl/NVCtrl.h#n2797 ) In Opera this change does not visibly influence the scrolling speed - it is fast in both cases. This may mean following things: a) Opera allocates (some of) relevant bitmaps in a way which ensures they land in video memory. This could be caused by their parameters somehow convincing the driver's heuristics to do the alloc in video memory. or b) Opera doing compositing in a more efficient way (less operations? different masking?) The second option seems more viable to me, as Opera is still fast even when pixmaps are forced to system memory. Can someone in the know tell me to where in Mozilla code compositing for pages with "fixed" elements is handled? Thanks.
Comment 210•16 years ago
|
||
Sadly you can't control this with stock nv driver :/ .
Miloslaw: thanks for the info. Maybe Opera is doing all the compositing locally and just sending the final result?
background-attachment:fixed elements aren't drawn any differently from normal. The only reason that parameter makes a difference is that it means each time you scroll, we have to redraw the entire window instead of just the scrolled-into-view part. Because of that, it's expected and necessary that scrolling a page with background-attachment:fixed elements is slower than background-attachment:scroll. The way we paint backgrounds is quite straightforward. We use cairo, and have the image in an xlib surface, and cairo tries to use Xrender to draw it to another xlib "backbuffer" surface, which gets drawn to the window at the end of our draw cycle. This is supposed to be the "right way" to do things but depending on the X server and the driver, it can be slower than just doing everything with the CPU in your own process. The performance problem might actually be drawing text, though, or anything else that's on the page. This bug is actually far too broad, it's really a "painting is slow" bug :-(. I want people to file new bugs on specific very slow pages, on specific platforms, and make them block this bug. Bonus points if you can simplify the page down to one or a few elements that are still slow. That's really the only hope we have of making progress here.
Comment 213•16 years ago
|
||
Do you mean that the entire page contents are redrawn, instead of just the part that is visible in the viewport?
No, just the part visible in the viewport.
Comment 215•16 years ago
|
||
It seems that it happens only when the size is not set to default (no matter if the page is enlarged or shrinked). Scroll is very slow if there is any fixed element, and resizing the page slows it much more. Firefox works very fast even on very complex websites without fixed elements. If I enter a basic website that contain at least one fixed element, it starts working slowly. If I will adblock an element (even floating "Hello" text), the website starts working properly. For example, on OGame there is a fixed background. Scrolling is very slow. Adblocking the background speeds up the site (it just works so smooth that it can't be better). Also I've noticed, that if the search bar on the bottom is active (the CTRL+F one), scrolling works slower (but still at acceptable speed). Closing the bar makes the page work lightning fast. @Miloslaw Smyk You are right, but on my computer this option slows down Firefox considerably (it works VERY slow on OGame site).
Comment 216•16 years ago
|
||
hi there! is there any modification i can make on my code? Thanks!
Comment 218•16 years ago
|
||
Hi, my friends... I was making some tests here - trying to discover why Firefox' appearance is so different (and uglier) from Windows to Linux - and could notice something about this problem here: A profile created in Windows works better in Linux (scrolling pages) than one made by default in Linux itself. I copied the paste of my profile in Windows and used the copy within Linux and now the scrolling is a little faster. I don't know if this information can help, but it is one more thing to consider. BTW, don't you thing this bug has lasted for too long? It is here since 2001 (7 years ago!) and apparently nothing changed. I can't code, I only can beg you to help. It passed the time to take an effective action to solve this problem. Someone has to take this problem to himself and dedicate all efforts to solve it. This community bug hunt isn't working anymore here. We all know that Mozilla likely don't care too much about Linux, but what I just can't understand is why Firefox can't be same in Windows and Linux. Opera (i.e.) is exactly the same software in both SO, the same in appearance and in way of work. I must confess I really considered to move to it and give up Firefox. Unfortunately (or not) I must be not the only one to think this way. Obs1: I know this problem (slowly scrolling) happens in both SO (I don't know about Mac), but it is much more obvious in Linux. Obs2: And it happens scrolling through mouse wheel or scroll bar.
Comment 219•16 years ago
|
||
I appreciate this will only be sorted by filing/fixing multiple bugs, but I just wanted to note that I'm seeing this issue more and more in day-to-day browsing. Here's an example of a recent site I'm having issues with (but there are many more): http://au.sports.yahoo.com/olympics/ I get very choppy scrolling on my Dell Inspiron 6400 (Dual Core 1.73GHz) with ATI Mobility Radeon X1400 graphics, whether or not powerplay is enabled. On my desktop (Core 2 2.1GHz with Nvidia 7600GS), scrolling is fine (there appears to be a little lag, but it's hard to see). This is with Fx3 and Fx3.1 nightly. Fx2 with these sites scrolls fine.
Comment 220•16 years ago
|
||
Confirming this issue ( http://au.sports.yahoo.com/olympics/ ) on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Also http://fronteers.nl/congres/2008/english (for reference: casual browsing, scrolling problems more often then FF2)
Comment 221•16 years ago
|
||
Is anyone working on this bug? With this bug, along with the bugs this bug blocks, firefox becomes unbearably slow. This is even true for the "Do you want to save password" pop up header animation at the top that appears when you log on to a site. The test cases and examples given in this bug and the ones this blocks are all related to either fixed backgrounds or fixed div elements, meaning all down to fixed elements. Most other browsers I tested with those sites are rendering the sites pretty well. I kindly ask the firefox development team to boost the resources on this bug, so we can continue to use our beloved firefox comfortably . Otherwise I think most of the users will have no chance but to look for alternatives... Regards, Hasan Ceylan
Comment 222•16 years ago
|
||
(In reply to comment #221) > Is anyone working on this bug? Not as such. See comment 212 - this is basically a meta bug now: > I want people to file new bugs on specific very slow pages, on specific > platforms, and make them block this bug. Bonus points if you can simplify the > page down to one or a few elements that are still slow. That's really the only > hope we have of making progress here.
I have made a lot of progress in another bug related to this. That should be fixed soon, then we can revisit this.
Comment 224•16 years ago
|
||
Thanks for the comments Robert... I hate to push too much, but any idea for a date to release a fix..?
Comment 225•16 years ago
|
||
(In reply to comment 212) Not sure if I should report this as a separate bug, but here's a specific page and a specific platform that scrolls very slowly. http://www.twitter.com/home Steps to reproduce 1) REgister for a Twitter account 2) "Follow" several Twitter users to populate your twitter.com/home page with several entries 3) Scroll twitter.com/home Problem: very slow scrolling Expected: normal scrolling Platform: vista sp1 86x firefox 3.0.4
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
Comment 226•16 years ago
|
||
@225 - that page is different for everyone since it's a user specific Twitter home page. The page ia VERY slow on my machine and has a large fixed background image: http://whatever.scalzi.com/ It's speedy on Safari, a bit slow on FF 3.0 and moves about one line per second on Shiretoko nightlys. Computer Info: Macbook Core Duo, 2g RAM. Intel GMA onboard video (64M). Shiretoko 3.1b3pre (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre). All addons disabled, though this did not perceptibly affect things.
Comment 227•16 years ago
|
||
@226 - I can also confirm the specified web site - http://whatever.scalzi.com/ - is extremely slow. It takes about a second to scroll a couple lines. My screen resolution is 2560x1600 and therefore the performance impact might be greater than lower resolution system. However, Opera just performs very fast with the same configuration, so I don't think this is a hardware problem. This issue is still here in the latest nightly build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090325 Gentoo Firefox/3.6a1pre
Comment 228•16 years ago
|
||
This is blazingly fast for me, in a currently nightly, fwiw. (on Mac OS X)
Comment 229•16 years ago
|
||
Also for me in linux that site is ok. not smooth at all but definitely fast (it skips to visualize things when scrolling, but it's fast)!
Comment 230•16 years ago
|
||
I think this might now be Linux-only.
Comment 231•16 years ago
|
||
The latest nightly is better (about a line per 0.5sec) but is still dramatically slower than FF 3.07 on this Macbook. Dramatically meaning about 3-4x slower. Note, BTW, that I can move down the page faster, but what I'm specifically doing is arrowing down (equivalent to clicking and holding the down arrow in the scrollbar). If I grab the page indicator in the scrollbar and move it up and down it's a bit hesitant, but acceptable.
Comment 232•16 years ago
|
||
For me, on Linux, the sites mentioned in previous comments work actually pretty well. I am using: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.7) Gecko/2009030503 Fedora/3.0.7-1.fc10 Firefox/3.0.7 All sites are working a little bit slower than usual, but they still work very smooth. I believe that this is because of new NVIDIA drivers. I remember that on older driver versions (prior to 180.xx) I've experienced this bug. But I can't tell which version of Firefox I was using then.
rickgregory@gmail.com: have you zoomed that scalzi page? How's performance at the default zoom level (cmd-0)? I suspect the scalzi site slowed down because it has a large tiled background image, and we changed our tiled image drawing to go through a temporary surface in some cases to avoid artifacts when zooming. But that should only happen when zooming is happening.
Comment 234•16 years ago
|
||
Robert.... Nailed it. For some reason the site by default comes up zoomed in one level. Setting it to default makes the performance fine, zooming back in degrades it again (unless the background isn't displayed because of the zoom level/window size combo). Thanks.
Assignee: vladimir → nobody
Component: GFX → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: general → thebes
Comment 235•16 years ago
|
||
Confirming that when site isn't on default zoom level it works painfully slow. Need to wait few secs to scroll 5-7 lines.
Comment 236•16 years ago
|
||
Robert O'Callahan.. Hm. There are users that use zoom on all sites. For example it's me. I surf websites on 42" flat panel - and have to use zoom. But fixed background not so rare thing. Sites that i use which very slow when zoomed: http://lxj.endofinternet.net/kde/ http://wii.ign.com - terrible slow, but on latest trunk it is little faster then on 3.0.7
Comment 237•15 years ago
|
||
Btw, I can't reproduce this on Linux with driver xf86-video-radeonhd 1.2.5-1. Scrolling works without any lag on both of testcases (tried with different zoom levels). Tough, when I was on Win XP with official ATI drivers, I could reproduce this without any doubt.
See Also: → https://launchpad.net/bugs/125588
See Also: → https://launchpad.net/bugs/125970
When bug 564911 lands we should reexamine all testcases and linked bugs --- most of them should be fixed.
Depends on: 564991
Comment 240•14 years ago
|
||
I guess you meant bug 564991
Yes indeed, sorry!
Comment 242•14 years ago
|
||
Looking good with 4b0436a4faf8 tryserver build.
Comment 243•14 years ago
|
||
The scrolling on this testcase seems to be smooth since retained layers landed. Roc, would you like to mark this one as fixed?
No, I would like you to mark this (and other bugs that are fixed) as fixed :-)
Comment 245•14 years ago
|
||
Very well. I just thought since you did all the hard work, you should get the pleasure of making these bugs fixed. -> Fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•