Closed Bug 372039 Opened 18 years ago Closed 14 years ago

[READ COMMENT #88 FIRST] Slow and laggy scrolling with fixed background, high CPU usage

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: stevee, Unassigned)

References

(
URL
)

Details

(Keywords: perf, regression, testcase, Whiteboard: [testcase in URL field]) 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070227 Minefield/3.0a3pre ID:2007022714 [cairo]

From the testcase (URL) I used to get a time of ~8700ms but now I get ~12400ms. Note when you run the testcase, the background image now jerks when the test is running.

Regressed between 2007022314 and 2007022316 --> due to bug 370379
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Summary: Scrolling regression → Scrolling regression with fixed background
Summary: Scrolling regression with fixed background → Scrolling performance regression with fixed background
using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070228 Minefield/3.0a3pre ID:2007022819 [cairo]

testcase result:
1. 6656ms
2. 6890ms
3. 6875ms
4. 6938ms
5. 6968ms

but yes, background image seems shaking.

(In reply to comment #1)

So you have a faster CPU. Alright. Pretty useless without a comparable result. That is, one that's older than 2007022316.
(In reply to comment #2)

using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070223 Minefield/3.0a3pre ID:2007022314 [cairo]

testcase result:
1. 4031ms
2. 4078ms
3. 4109ms
4. 4218ms
5. 4098ms

thus confirming perf regression here.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Depends on: compositor
Blocks: 375400
No longer blocks: 375400
After the landing of bug 343430 I no longer see this bug's testcase's background jerking, but the times are not as low as they used to be (~11536ms now).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 Minefield/3.0a5pre ID:2007052722 [cairo]

No jerking background.
scrolling from ~7200ms->~7000ms
(In reply to comment #4)
> After the landing of bug 343430 I no longer see this bug's testcase's
> background jerking, but the times are not as low as they used to be (~11536ms
> now).
> 
Strange. After the patch for bug 343430 landed I now see scrolling times much faster than with Firefox 2.

I think this about as good as we're going to get for 1.9. I think we should make this no longer block.
Flags: blocking1.9+ → blocking1.9?
I decided to be a bit more scientific than a single run for each browser to test this, so I averaged 5 test for each browser.
The average came out with the trunk being 8 milliseconds slower

Trunk:           4672 (4672, 4719, 4688, 4610, 4672)
Firefox 2.0.0.3: 4665 (4797, 4578, 4609, 4687, 4656)
Opera 9.10:      6231 (6250, 6234, 6219, 6219, 6234)
Same data, deleting high and low and averaging the other 3.  I think this probably give a more accurate picture:

Trunk: 4677
FF2:   4651
Opera: 6229
Sorry for the bugspam.  I neglected to mention that these numbers are Windows/XP.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 Minefield/3.0a5pre ID:2007052722
I think the move to cairo is the reason why the scrolling is slower in current trunk builds.
Bug 361754 is a similar bug with a similar testcase like this.
Well the difference now is definitely within the noise range.  The granularity of the clock on my system is only 16 milliseconds (typical of windows systems) and the difference between Firefox 2 and current trunk is 26 milliseconds, so this is virtually a tie.
I see a higher cpu usage during scrolling with current trunk builds (50%), compared to branch builds (<10%).
So I think that when I would have a slower cpu or made the testcase more cpu intensive, I would see a difference in speed.
I think the remaining issue is now basically the same as bug 361754.
Depends on: 361754
(In reply to comment #12)
> Well the difference now is definitely within the noise range.  The granularity
> of the clock on my system is only 16 milliseconds (typical of windows systems)
> and the difference between Firefox 2 and current trunk is 26 milliseconds, so
> this is virtually a tie.

Then obviously not every computer gives the same results ...

Firefox 2   6812  6828  6797  6828  6891
Firefox 3  10547 10531 10532 10547 10578
Opera 9.21  6219  6218  6219  6218  6235

All tests done in fullscreen mode, with toolbars hidden. (To make sure that the window size is the same every time.)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070529 Minefield/3.0a5pre ID:2007052909 [cairo]

I suspect this is fundamentally a cairo image drawing issue.
Keywords: perf
Well, or more likely a video driver drawing issue.  Depending on the types of images at play (DIBs or DDBs) and the destinations (DIBs or DDBs) we could see different performance characteristics.  I had a benchmark sitting around somewhere that tested the various combos and reported the results, but i'm not sure where that went.  Could also be a Win2k vs. WinXP thing as well.
Well, whatever the cause I am seeing an approximate 13% performance regression on this test compared to a month ago.  Windows XP same hardware.
(In reply to comment #16)
> I had a benchmark sitting around
> somewhere that tested the various combos and reported the results, but i'm not
> sure where that went.

You made it for Bug 328380
http://people.mozilla.com/~vladimir/misc/gdibench.exe

(In reply to comment #17)
> Well, whatever the cause I am seeing an approximate 13% performance regression
> on this test compared to a month ago.  Windows XP same hardware.
> 

Confirmed,it takes ≈ 12% since last month.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
I tested the url and I don't see any background distortion, and the performance is quite the same on Fx2 and Fx3. What I noticed is only an higher HD activity with Fx3. Tested on blank profiles.

Since the bug is old, can you retest posting also you video card?

ATI Radeon X1200 (integrated chip on the motherboard)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre
I have nVidia GeForce 6200 (AGP).

Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9pre) Gecko/2008060904 openSUSE/10.3 Minefield/3.0pre

When using Metacity - that's not so bad, but Metacity experience is not so nice.

When using Compiz - that's very bad, but Compiz experience is nicer than Metacity.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre ID:2008060906

Five measurements with
Fx3:  9283 9106 9035 9212 9116
Fx2:  6765 6765 6703 6719 6766

I have an integrated Intel GMA 900 graphics accelerator.  Both tests were done in fullscreen mode (with toolbars hidden for Fx2), 1280*800 screen resolution (because results are dependent on the window size).

However, this small difference (i.e. Fx3 being only ~35% slower) does not reflect the huge difference in scrolling speed that I see on some sites, such as http://www.cssmagazine.it/.  On that site I can easily count redraws with Fx3 (depending on the scroll speed, it might be as bad as 3-4 frames/second with autoscroll), while the site is perfectly usable with Fx2 (while scrolling is slower than sites with no fixed elements, it is impossible to count redraws with a naked eye).
(In reply to comment #21)
> results are dependent on the window size

You are right, now I can confirm the bug with a resolution of 1280x1024 (the speed is halved). With a 800x600 resolution the performance of Fx3 is the same of Fx2. Furthermore the performance of Fx2 is the same with a 1280x1024 and 800x600  resolution. So scrolling performance with Cairo libraries are very dependent from the screen resolution.

I can notice some slow down, also with 80x600 resolution, scrolling the page you signalled - http://www.cssmagazine.it/ - especially at the top and bottom of the page.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Blocks: 441161
Blocks: 441460
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
view www.mypawbook.com and notice when scrolling up and down it is slow. Also the flash and script elements lag behind overlapping or going out of their tables temporarily. This does not happen in IE7 so a video card issue doesnt seem to be the reason for this.
Special case (Duplicate) of Bug 201307? It's related to scrolling performance of pages with position:fixed elements in general.
OS: Windows 2000 → All
Whiteboard: [DUPEME] see comment 28
(In reply to comment #28)
> Special case (Duplicate) of Bug 201307? It's related to scrolling performance
> of pages with position:fixed elements in general.

This regressed after Firefox 2. Bug 201307 existed before Firefox 1...
Whiteboard: [DUPEME] see comment 28
I'll repeat the report from the just closiplated 444871 in the hope that it'll help people look at this. The bug is at the moment making FF3 unusable for me now that I'm seeing this on more sites. Will need to go back to FF2 or probably Opera...

Resolution is 1280x1024 (on a Matrox Millenium G550 AGP).

URL: http://www.bnrmetal.com/v2/search.php?name=black+sabbath

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9)
Gecko/2008052912 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9)
Gecko/2008052912 Firefox/3.0

The above mentioned site (www.bnrmetal.com) has become unuseable with firefox
3, at least on my hardware.

I'm on a Duron 1300 and while scrolling any page on bnrmetal, X takes some 90+
% CPU with the remaining 10 going to firefox-bin itself. Trying to *stop*
scrolling after a good turn of the scrollwheel for example can take up to 10
seconds even...

I just now tried with firefox 2.0.0.15 as well and although that (now that I am
paying attention to it) takes quite a bit of CPU as well it's not nearly as
bad. The site is still useable with it. I contacted the owner who isn't aware
of anything wrong, and Opera 9.50 has no trouble with the site whatsoever it
seems. It's lightning fast...

Reproducible: Always

Steps to Reproduce:
1. go to above URL
2. scroll page with scrollwheel or down arrow under right scrollbar
3. see it bring your system to its knees -- probably unless you have a very
fast system.
Actual Results:  
A system on its knees

Expected Results:  
A system not on its knees

Verified on various Linux kernels (and browsers as mentioned in the report)
Additional information: I just tried after lowering my screen resolution to 800x600 and even 640x480 and this is not making an appreciable difference. Still unusably slow that is.
Depends on: 445020
This bug is a lot worse when the fixed background image is large. Otherwise, 3.0.1 fixed it (with the exception to page zoom)
(In reply to comment #35)
> 3.0.1 fixed it (with the exception to page zoom)
> 

No, this was not fixed in 3.0.1


I dont see it as being fixed. check out www.mypawbook.com and tell me why the script and flash elements lag behind when you scroll up and down really quick (ie: the shoutbox). This is an issue related to the fixed background because when i take off fixed background, it doesnt do it anymore and in IE it never does it.

Scrolling is also a little slow on it too.
I checked out http://www.bnrmetal.com and well the scrolling is a bit slow but its bearable. I think its an issue with fixed background css property and firefox 2.0 or 3.0 or 3.0.1 and the problems will be worse on people with slow systems or perhaps less RAM or Video RAM perhaps.  The slowing down is your computer processing for firefox. Try and load up firefox and then hit ctrl alt delete and bring up processes and see how much memory firefox is using up. Then go to a slow scrolling page and check the memory usage after the page is loaded and you have scrolled up and down a couple times. About an 8 meg jump which isnt too bad.

Well I'm glad multiple people agree there's still something wrong. It definitely is a LOT worse with large background images (fixed). The fix implemented for 3.0.1 seemed to only help very small fixed background images.

It is still unacceptable that I need 100% cpu to scroll and it gets laggy when this does not happen in inferior IE.
i dont agree its a LOT worse. its pretty much the same for me. I have tried saving the background image in Photoshop as 100% and 60% and there wasnt much difference. Firefox just has to handle the css property better and take a lesson from IE and get it right and then Firefox will be number 1 in my eyes again. :)
Also Firefox needs to take into account people with slower computers and cater to them exclusively. If they do this , then everyone will be happy, so i hope they are testing this on a Pentium 4 Celeron with 512mb RAM and low end vid card with avg internet connection.
Flags: blocking1.9.1?
Matt: the bnrmetal site is unuseably, ludicrously slow on a Duron 1300 with 768M and a 32M AGP card, at any resolution, with Firefox 3 under Linux. Scrolling is mostly impossible and as said, trying to _stop_ scrolling can take up to 10 seconds or so even.

As described in the report, firefox 3 together with its rendering companion (X) is taking all CPU. It's much better in Firefox 2(0.0.15), no problem to be seen in Opera 9.5. Very fast.

Quite frankly, if a 1+ GHz CPU with "lots" (quite enough in any case) of memory is too slow for Firefox 3 rendering the bnrmetal site then I definitely know which one of the triplet (my system, bnrmetal site, firefox 3) has a problem. This is not a "slower computer" with "computer" defined as a webbrowsing workstation.
(In reply to comment #42)
> It's much better in Firefox 2(0.0.15)
> 

Exactly. This is a regression bug, and you can see the difference between Fx2 and Fx3 with the testcase in URL. See also Comment #22
Whiteboard: [testcase in URL field]
Changing title to lower duplicates.
Summary: Scrolling performance regression with fixed background → [Fx3] Slow and laggy scrolling with fixed background, high CPU usage
Rene: your computer is a pretty slow computer. i understand a computer such as yours should definately be capable of simply browsing the internet, but it depends on your Operating system, RAM and because of Firefox's increased use of memory, your browser.

try this edit in your firefox config to speed up the scrolling.

Change two values in about:config

enter “about:config” in the address bar

ok if it warns you

change the keys below,

mousewheel.withnokey.sysnumlines (change from true to false)by clicking on the line once.

AND

mousewheel.withnokey.numlines (change this to 6)by clicking on the line once and changing the value from 1 to 6

this works for me and now wbesites with fixed backgrounds scroll quickly 

HOWEVER: from a web designers standpoint, how can we expect all viewers of our sites to edit this to fix the issue?!?!!

Firefox should have this preconfigured prior to people installing it so they dont have to edit it themselves!!!




@Matt Godwin: this could be a workaround, but this bug is clearly a regression, since the testcase is faster with Fx2. Much people have reported this problems.

This bug probably will be fixed by Bug 446376
Depends on: 446376
Well my bug report https://bugzilla.mozilla.org/show_bug.cgi?id=449998 is duplicate of this bug, I would like to note here that this bug is exposed also with fixed positioned divs.
I've had to go back to firefox 2.0.0.15. The issue is far to common on the web to be able to sanely use Firefox 3 here.
(In reply to comment #51)
> I would like to note here that this bug is exposed also with fixed positioned 
> divs.
> 

This is Bug 201307, this bug 372039 blocks it.
FYI

Performance hit changes based on the the size of the viewport a lot.
(as commented before, #31) for me the viewport size does not seem to matter. This probably just means that Firefox grabs enough CPU to for me still totally overtax my system even at the smallest size  (information in #30) while for others it's getting to be just doable at some smaller size.
(In reply to comment #55)
> for me the viewport size does not seem to matter
> 

That sounds me strange. Can you post your results with the testcase with your max and min resolution?
Lucas: Yes, but the testcase in the URL field might not be all that relevant. It behaves as expected:

1280x1024: 7411ms
1024x768 : 4914ms
800x600  : 4288ms

However, and this is not meant aggressively or anything, I couldn't really give a hoot about the artificial testcase simply since I don't spent my days refreshing that testcase :-)

Some individual closed the bug I originally entered (comment #30) and marked it as a duplicate of this one -- for all I know, it isn't even. As said just below the thing you quoted, I expect that at least with my real-world testcase (bnrmetal, #30) the issue is that my system (1300 MHz CPU) is just south of the mark even on 800x600 while for others their system does turn out to be just enough at lower resolutions to hide the problem.

Can't stress enough how fast Opera 9.5 is on it... :-/
Well, you can say "it's slow anyway", but the fact that the scrolling time is directly proportional to viewport size is true, and could help to understand what part of engine need to be improved, since for Fx2 the viewport size doesn't influence so much the speed.
Lucas, would you be able to confirm though that the bnrmetal site issue is the same issue though so that I'm at least confident that I'm in the right place? I don't know how to do do that myself.
Confirmed in my Firefox 3.0.1 and Windows XP SP2.
Can confirm it in the latest 3.0.2 build for XP.

Some realworld examples are http://sga.gatech.edu and http://www.pspublishing.co.uk
Both realworld examples given in #61 confirmed with 3.0.1 on Linux 2.6. Both pages almost impossible to scroll here.
Terrible scroll lag here: http://www.98rock.com/cc-common/new/6/indexrock.html
Terrible scroll lag here: http://www.98rock.com/cc-common/new/6/indexrock.html

I can confirm, and this is for sure related to background - adblocking it gives the page a great boost.
Blocks: 424529
The attached test gives me 9646ms on Firefox 3.1 Beta 2 on Vista Ultimate @ 1920x1200.  Core 2 Quad Q9450 (2.66ghz), 4GB RAM, Nvidia 9800GT 512MB, etc.
It seems it might be related to video drivers.

This bug is already fixed on Linux (with new NVIDIA BETA 180.16 driver), but still occurs on Windows. It seems that Windows doesn't have proper 2d hardware acceleration, or maybe it's some video memory related problem.

On Core2Duo 2.53, NVIDIA 8600 and 2gb RAM, Fedora Linux 10 @ 1680x1050 it gives me 4018 msec - very smooth scrolling.

On computer I am at right now (at work, Intel Core2Duo 2.40, 2GB RAM and Intel Q35 express card with Windows XP Professional) it gives me 9801 msec - choppy scrolling.

On Linux, no matter what the zoom level is - it works perfect.
On Windows, it works best (but still slow) at default zoom level. Shrinking or enlarging the view makes the scrolling very slow.
Reply to #68:

This is NOT a video driver issue. Firefox 2 works well -- I had to experience the FF3 slowdown to notice any laggyness with FF2 (and none with Opera).

I'm on Linux, problem exists both on a Duron 1300/Matrox G550 AGP and a Pentium 4 3.0G / Intel 865G system. Haven't tested 3.1 yet, will do when it's out.
Reply to #69:

This IS a video driver issue.

Gecko changed a lot from FF2 to FF3. New Gecko is very sensitive to driver bugs.

I have two video drivers for my graphics card: NVIDIA binary driver 180.16 and open-source nv driver. Results:

http://alarm-clock.54.pl/nv.png         <-- open source driver
http://alarm-clock.54.pl/nvidia.png     <-- NVIDIA binary driver

Test were run on the same computer, one test 2 minutes after another, same window size.

With this new driver (introducing GlyphCache) Firefox runs extremely well (iGoogle widgets are VERY smooth when snapping to a position, there is no 20-30msec delay) - you can feel like its working in OpenGL.

With the NV driver, there is a small delay with iGoogle widget snap, scrolling is not very smooth with fixed background.

This is a problem with Gecko (it seems previous Firefox versions handled driver issues better). A little hint:

If you switch Firefox to zoom text only (View->Zoom->Zoom text only), it will work at full speed, no matter what is the current zoom level.

Zoom level affets speed even on NVIDIA driver (with the default zoom it works fine).
In regards to my post, #67, I am using the WHQL Nvidia drivers v180.48 on my Vista machine.  On a side note, the latest version of Chrome does the same testcase in 9526ms.
On the second thought...

NVIDIA made some great improvements for the Linux display driver.

Videos are scaling very smooth (no tearing or delay at all), GTK is working amazingly fast (Cairo speed improved a lot), everything is just 10 times faster.

Maybe this is it? Firefox renders through Cairo, if cairo is faster then Firefox got speed boost?

Anyway, Firefox is using cairo badly, because WebKit is able to be smooth on the old driver.
Regarding the nVidia driver issue.  I just upgraded my nVidia GEFORCE 6800 to the latest driver for that card and the test case improved over 1200ms (the average of three runs) compared to what it was prior to the driver upgrade!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081222 Minefield/3.2a1pre ID:20081222023749

~B
#70/#72:

Exactly. Firefox is doing something which causes a enormous slowdown on the vast majority of systems between FF2 and FF3 -- which quite definitely makes it not a driver issue but a Firefox issue according to my definitions.

I'm rather sensitive to this being written off as "solved" or something when it's not all that likely that for example my G550 will even _ever_ have a driver available which nullifies the effect of said bhaviour. Really, to appreciate the "okay, right, this won't do" effect of this issue, try a legacy system. I've had to downgrade to FF2 -- it's otherwise simply unworkable.
There is confusion in this bug, as there are two different platforms being talked about that happened to have the same symptoms.  On Win32, there were some issues that were fixed in various ways (and may still be optimized further in the future, as, annoyingly, different drivers implement different pieces of the GDI disaster).

On Linux, Firefox 3 uses the RENDER architecture for graphics rendering; Firefox 2 and before used straight xlib.  Switching back to xlib is not an option, as it does not provide functionality that Firefox (and other apps that switched to RENDER, such as the gnome desktop) depend on.  Some drivers obviously have subpar support for RENDER.  This is unfortunate, but is something to take up with the driver vendor (if any), or with the linux community and X developers.

This bug should probably be closed and separate issues filed for the discrete problems, instead of having them all conflated in one spot.
If this is in fact a driver issue or a users computer issue, then why does fixed backgrounds always perform excellent with Internet Explorer?!?!

Why is Firefox the only culprit?!?
Matt, in comment 75, Vlad is discussing issues with drivers, but that doesn't mean he doesn't think that slow scrolling issues are not a problem in Firefox, especially when it used to work in older versions of Firefox.
Please file a new bug, mention a testcase where you see the problem, and also mention what video card you use, etc.
Blocks: 437178
Also happens to me with Firefox 3.1 B2 on Fedora 10 with both nvidia and nv drivers here: http://vrr.de/de/index.html
Flags: blocking1.9.2?
This bug is very evident when browsing profiles on Myspace. 99% of the profiles on Myspace have some sort of a fixed background and almost any kind of activity involving Myspace is horribly laggy with Firefox 3.1b4pre. I'm on Vista Ultimate SP2 32bit w/ latest WHQL drivers from Nvidia for my 9800GT. Testcase on build 20090316095712 is completed in 13107ms. 3.5 seconds slower then I reported with 3.1 Beta 2 back in December.
Ran the testcase again with 3.5b4pre Nightly Build 20090417045158.  17513ms.  Very disappointing. Almost 4.5 seconds slower then it was a month ago. I'm on XP SP3, latest WHQL drivers for my 9800GT @ 1920x1200@60hz.
Confirmed. I am on Ubuntu 9.10, Firefox 3.0.10, on a Dell Latitude D520--that has an Intel 945GM video chip. 1.66GHz Centrino Duo. 1024x768. Let me know if you need more information.
Also happens with many MySpace pages such as http://www.myspace.com/thetorpedomonkeys . I have the same problem using Midori / Chrome(WebKit) under Linux but not when using Internet Explorer under Windows.
My times...

FF3.5: 3938ms
Chrome2.0.172: 4080ms
Opera9.64: 5891ms
FF1.0: 10334ms
FF2.0: 8406ms
FF3.0: 7695ms

IBM Thinkpad T60 with Intel C2D 1.83Ghz, 2.5GB RAM
9884ms w/ Minefield build 20090709091211 @ 1920x1200 resolution and Core2Quad Q6600 (2.4ghz), 4GB RAM, Vista Ultimate 32bit, GeForce 9800GT (512MB), latest WHQL drivers.
On Firefox 3.5, my test result is 4099. Previously it was something like 8000. I am using 1680x1050 resolution.

Seems that Firefox 3.5 fixed the issue? My comp Core2Duo 2.5GHZ, 2 gb ram, GeForce 8600, Fedora 11 with 3D drivers from repo.
Please do not add other tests, this bug is well confirmed.

The only workaround I can suggest is to lower your screen resolution, set images.dither to false, disable unneeded extensions and plugins and check for the latest video driver. Try betas if you are adventurous.
Summary: [Fx3] Slow and laggy scrolling with fixed background, high CPU usage → [READ COMMENT #88 FIRST] Slow and laggy scrolling with fixed background, high CPU usage
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
On the same machine, OS, screen resolution:
7800ms on FF 3.6.12
4600ms on FF 4b8pre (2010-11-14 build)
It seems fixed to me (not surpring at all, when considering the FF4  extraordinary work on performance issues) and I am marking it as such. Please test with the latest trunk build and re-open if the bug still exists.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Forgot to include OS info (Windows XP), video driver info (Nvidia 2/5/2008, a really ancient driver indeed). I hope performance is not lacking on the rest of main platforms. And sorry for spamming.
Still not fixed for me on this page: http://fixedbackground.blogspot.com/ . 100% CPU plus slow scrolling fps.

Windows 7 32-bit, Core 2 Duo 1.8 GHz, Intel 945GM. Did not lag during the initial Compositor landing, started to lag only when the new-fangled GPU-acceleration code came in. Unacceptable situation because I KNOW that it didn't lag when there was no hardware acceleration, but does for unqualified GPUs now.

Do I open a new bug?
You need to log in before you can comment on or make changes to this bug.