Closed Bug 413280 Opened 17 years ago Closed 17 years ago

Very slow scrolling

Categories

(Core Graveyard :: GFX, defect)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 422330

People

(Reporter: r_rom, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

Sample file causing slow scrolling
46.40 KB, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008011715 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008011715 Minefield/3.0b3pre I am pretty sure this bug report is a dup of an existing one, but I don't know which one, so I am filing this just in case it will reveal useful information. Slow scrolling, and you can see how lines morph as you move the page. Reproducible: Always
Version: unspecified → Trunk
WFM with Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008020404 Minefield/3.0b3pre Scrolling is slow, but far from being as bad as with some Wordpress blogs. And that’s with the nouveau driver…
Would you post URLs of some of these blogs?
It's slow for me to, when using FF3. FF2 responds much quicker.
Attached HTML file renders slowly and causes very slow scrolling in FF3b5, also latest build as of 17th March 08. Dragging the scroll slider can freeze the PC for several seconds. This is on Ubuntu Linux 7.10.
But on my PC with Vista, the file is rendered and scrolled very fast. By the way, the page at the URL I posted in my initial comment works great now too. I hope it's caused by improvements in FF, not changes in the page. This is with 2008031605 build.
Hmm... both work well in FF 2.x too.
Hmm. It's very poor still with last night's build on Ubuntu Linux. In fact I think it's a rendering issue. Switching tabs between this bug report and the attached file takes 2.5 seconds to render using the laptop described in the file. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031704 Minefield/3.0b5pre I wonder if I should be creating a new bug instead of tail-ending this one then. I think I will, since this one is marked as Vista OS and you have no problem there any more. I'll have to undo my vote.
Having very similar problems to those described here (including the slow switch between tabs). Using Windows XP, using beta 4 build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 Works much better (wouldn't say perfect, but smooth enough to not be annoying) in FF2 build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Sample URL: http://wiki.ffxiclopedia.org/wiki/Campaign_Operations
David, I've been using beta 5 builds and have no problems with any of the pages listed here, even the one I reported initially. Why don't you try a nightly build and see if your problem is gone? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Have you considered the possibilty that the problem might only appear on slow computers? Mine for example is: Pentium 3 - 1.12GHz, 512MB of Ram, running WIN XP.
On computer speed: I have an Intel Core2Duo 6750 (2.66 GHz), 2 GB RAM. That shouldn't be the limiting factor. Trying latest nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre), it's significantly better. Not seeing the tearing/lagging unless 1 processor is close to maxed out. Doesn't seem to take advantage of the second processor very well, but that's another issue entirely.
I filed this issue using the same computer I am using now. I had this issue then but don't anymore. Combined with David's comments, this seems to mean that this issue has been eliminated. Let's see if others confirm this when they try one of latest beta 5 builds.
OK, I've now tried the latest trunk (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032304 Minefield/3.0b5pre). I'm still witnessing the same CPU-at-100-percent situation + slow scrolling. This does not happen to me with FF2.
What's the URL, Geva?
I still see problems with Gecko/2008032304.
Been messing around with this a bit more. Updated to newest nightly, testing on clean profile as well as normal profile (with and without plugins enabled), and using sysinternals' ProcessExplorer to record CPU usage while scrolling. While it's certainly better than beta 4, it still has issues. Scrolling (just continuous scrolling up and down using the mouse wheel) caused CPU usage in the 10%-30% range on the wiki page, with occasional spikes up towards the 40% level; since that's on a Core2Duo, consider it 20%-80% usage for a single CPU/thread. On the thesecret page I didn't encounter as much of an issue. CPU usage was a far more steady 15%-20% (so 30%-40% for single CPU). The vast majority of CPU time seems to be in kernel space rather than user space, but I'm not sure where to look to get any more specific than that. For comparison purposes, scrolling the wiki page in FF 2.0.0.12 has CPU usage in the 5%-13% range, and with effort I could get it to spike to 17% (1 CPU scale: 10%-26%, spike to 34%). That's also with 10 extensions active. Figure 20% typical for FF2 vs 40%-60% typical for FF3b5.
Flags: blocking-firefox3?
The OS should also be changed to ALL. It's not a Vista problem.
Changing OS to ALL. David, does ProcessExplorer show in which space CPU time is spent?
OS: Windows Vista → All
--> Core::GFX, though I'm not sure if that's the right component. I know that Vlad's seen stuff like this on OSX where we batch scroll events and take a long time to process them ...
Component: General → GFX
Flags: blocking-firefox3?
OS: All → Windows Vista
Product: Firefox → Core
QA Contact: general → general
Flags: blocking1.9?
Mike, why did you set OS back to Vista? People see it on XP and Linux too. And now you said OS X as well.
Hello Borders! (Pretty sure at least -- easy way to verify, get rid of all the border style bits and see if it's still slow to scroll. Not blocking on border rendering issues, though I am working on them for a fix for final.)
Status: UNCONFIRMED → NEW
Depends on: 424423
Ever confirmed: true
Flags: blocking1.9? → blocking1.9-
Roman: It shows the difference graphically, but not numerically. The numeric values shown on the graph are total CPU, and the graph itself has a red segment for kernel space and green segment for user space (technically user+kernel, with the margin between the top red line and the top green line being user). I would estimate kernel time typically being 90% or so (ie: vast majority). Vlad: That definitely makes a difference. I saved a local copy of the wiki page (and the saved version still had the CPU usage issue), then changed the border style of the two main problem tables (Campaign Ops and Medal Progression) from border="1" to border="0". After that, CPU usage while scrolling didn't go above 15% (30% single). That's about the same level as FF2. On the thesecret page, every single table is either border=0 or unspecified, as far as I can see. They do have some border values specified in CSS, though. Since my system doesn't really have much problem with that page, I'll let someone else test it.
Is there a way to rollback to FF2 in ubuntu linux until this bug gets fixed?
FF 3 uses a different graphics engine, so, I guess the answer is no.
The sample file scrolls slowly and with lag. The problem also occurs in GMail "newer version" when you have many messages. GMail "older version" works fine. Epiphany also presents the same problem; Galeon works fine. I'm using Ubuntu Hardy Heron 8.04 (32-bit), Firefox 3.0 Beta 5, nvidia driver (GeForce 8600GT).
Dupe of bug 422330 based on comment 22 and 23.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
I don't think this is a dupe of bug 422330 as mentioned above. Today I installed Firefox 3 from the previous Firefox 2 stable version. I'm very sad to say that I'm having this same problem affecting my site: http://www.darkmatters.org There is heavy use of png which I am guessing is the catalyst to this problem. Like Roman this is likely a transparency issue though I can't even guess as to why FF2 works fine but FF3 does not.
Correction: http://darkmatters.org
Removed "fixed" from CSS controlling background which has largely resolved the problem. However I would prefer my background to be fixed so am hopeful for a solution.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: