124150 - (100%CPU-bg) 100% cpu usage when scrolling page with large background image

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P1)

Description

[u43589]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

100% cpu usage when scrolling. Either with the mousewheel, keyboard keys or the
scrollbar.

Reproducible: Always
Steps to Reproduce:
1.visist http://www.bullseyecrosshairs.com/ , try and scroll the page.
2.
3.

Actual Results:  100% cpu usage, jerky mouse (usb)

Expected Results:  less cpu usage :)

Comment 1

[R.K.Aa.]

dup of bug 113190?

Comment 2

[djk]

Probably not a dup of 113190.  That bug is Linux.  I can't repro that one on
.0.9.8 on windows98.

Going to the url in this bug and scrolling slows mozilla down quite a bit.  I
think it has something to do with the HUGE .png background
(http://www.bullseyecrosshairs.com/newbg8.png).  Or possibly the large number of
tables/font tags/repetitive style attributes in the page...

Comment 3

[Brant Gurganus]

Using build 2002020409 on Windows XP, scrolling causes CPU usage to go to about
70% for the mozilla.exe process.

Comment 4

[Joonas]

I'm using Windows 2000, build id 2002020803 and a usb mouse. Scrolling the page
causes 100% cpu usage and a slighly jamming mouse for me too.

Comment 5

[Patrick]

Seeing the same on:
http://www2.pagesdor.be/htm/rublist/fr/A.asp?from=search&fullsearchmode=0&page=
This page also contains a large background image (a gif one).
Could someone confirm (or not) on a non-windows system?

Comment 6

[Steve Simms]

Testcase: removing the picture from the page eliminated the choppiness on the
reported URL.

I consistently get 50-99% CPU usage when scrolling with the mouse (PS/2 in this
case), not specific to any page.  Using Page Up/Page Down on a large page (e.g.
unconfirmed Win2k Mozilla bugs) brings CPU usage up to about 35-50%, and using
the arrow keys on the same page causes it to hover in the 60-70% range.  None of
these cause choppiness on most pages.

For comparison's sake, IE6 gives me 60-99%, 99%, and 99% on all three of those
measurements, so I'm guessing the CPU usage for scrolling is normal.  In IE's
case, arrow-key-scrolling was much choppier than Mozilla.

Comment 7

[Russell Odom]

Confirming on W2K 2002032203, and resummarising. I get very jerky scrolling and
80% CPU usage. Reassigning to Compositor - I hope that's the right place :-)

Comment 8

[Kevin McCluskey (gone)]

I get slow scroll performance using 7/1/2002 1.0 branch build on WinXP. 750Mhz
Athlon.
->dcone.  

Comment 9

[Jerry Baker]

This not only affects scrolling, but it appears to affect anything that involves
repainting anything on the page. For an example of insanely slow JS image flips,
see http://www.exactaudiocopy.de and try the menu in the left frame. Save it and
try it without the background image.

Should I change the summary to reflect that all screen paints are affected, or
open a new bug?

This is really hurting Moz peformance on lots of "normal" pages.

Comment 10

[Markus Hübner]

Also affecting common DHTML

Comment 11

[Nicolas Combelles]

More tests: 
Comp: Athlon 750Mhz, ram=384;
OS: Win2000
Browsers : IE55/Moz1.0

1) http://www.bullseyecrosshairs.com/ : I confirm the slow repainting while 
scrolling on moz.
+ http://www.bullseyecrosshairs.com/newbg8.png : faster now but still a little 
slow (but who would make a so big background image ... ).
2) http://www2.pagesdor.be/htm/rublist/fr/A.asp?
from=search&fullsearchmode=0&page > No pb on IE nor on Moz. 
3) http://www.exactaudiocopy.de > Repainting is a little slow for IE, much 
better with Moz ! About the menu's rollovers .. I see them normal.

Considering Comment #6 I think Moz does it well. Maybe a pb with the png ?

Fredrik (reporter)> can you make two files the same height*width (a png and a 
gif) ?
Moz repainting perfs are slower (see all the perf bugs) so it is normal big 
images repainting shows poor perfs. I think : If not a particuliar pb with png 
this is a dupe.

Bug should be called "Big background images cause slow repainting". (is it 
only "background" images ??).

Comment 12

[dcone (gone)]

I recently fixed a bug with animated gifs that was causing slow scrolling.  Also
PNG performance with alpha was fixed.  It would be very important to know what
the images are, what is the graphics card setting (256 is much slower than
millions of colors, if the image has alpha, image type (minor issue only for
loading since we store all images in a universal format (DDB if we can)).

Comment 13

[Markus Hübner]

http://www.exactaudiocopy.de 
for example being choppy and mouse-over of left menu-items is not very 
responsie (really slow).
using trunk build 2002071108 on win-xp pro,1.1ghz,512ram,GeForce2 Go (32MB) at 
32bit color-depth.

Comment 14

[Jerry Baker]

In response to dcone:

- 32-bit color depth
- Image has no alpha
- Testing with images in jpg, gif, png format show the same problem

Pages with large bg images are nearly unusable on my Athlon 800 machine. Scroll
acts more like page down with a delay than a scroll.

Comment 15

[dcone (gone)]

I think this is a duplicate of 148598, and I have a patch in for that.  I am
marking this as a dup.. and please try your test cases with the installed patch
and  see if performance goes up... I bet it does.

*** This bug has been marked as a duplicate of 148598 ***

Comment 16

[Dimitrios]

Tested with 2002080119/Win2K. It stills scrolls very choppily (450MHz cpu) and
crashes when reaching end of page. TB ID 8915310E. Reopening.

Comment 17

[Dimitrios]

Forgot to say that it isn't fixed for the original testcase url
http://www.bullseyecrosshairs.com/ . Sorry.

Comment 18

[Jacob Kjome]

I can verify the crash using build 2002080208 on Win2k (sp2sr1).

Talkback ID:  TB8924824Z

Added "crash" to keywords

Jake

Comment 19

[Kevin McCluskey (gone)]

nsbeta1+

Comment 20

[Wesha]

*** Bug 163542 has been marked as a duplicate of this bug. ***

Comment 21

[Jacob Kjome]

With the updated fix for bug 148598 I no longer see any crash and the scrolling 
seems adequate.  IE is still slightly better, but not too much.

This bug can probably be marked WFM or Fixed.

Jake

Comment 22

[Markus Hübner]

Using trunk build 2002081908 still same slow as reported in comment #13.

Comment 23

[Michael Baffoni]

Bringing over info from duped bug #163542:

Choppy behaviour and 100% CPU at http://www.idefense.com/papers.html when
scrolling, however, less than %20cpu (on a AMD1800+, 512MB system)and no chop in
Netscape 4.79 and IE 5.5.

An interesting factoid: Netscape 7.0PR1 only achieves some 55% CPU and no
choppiness when viewing this page.

Comment 24

[Brandon Streiff [:bstreiff]]

I've got jerkiness and 100% CPU usage on the http://www.bullseyecrosshairs.com
site with Mozilla 1.1 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826), on Win2K Pro, 500Mhz Pentium III with 128MB RAM.

In addition, the same bug exists on http://www.xiph.org (8x2048px bg image) and
http://www.livejournal.com (2x3000px bg image)

Comment 25

[Chris Gushue]

There is another problem, which seems like it might possibly be related to this.
If there is a large image on a page, but scaled down using width and height in
the image tag, Mozilla gets really choppy (and probably uses a lot of CPU at the
time, I haven't checked) as the image scrolls onto the screen.

Test case here: http://krypton.blackplasma.net/test.php

This is with Mozilla 1.0.1rc2 on Windows 2000 (but the bug has been present in
many previous builds as well - haven't checked 1.1/trunk builds lately).

Comment 26

[Markus Hübner]

http://krypton.blackplasma.net/test.php
isn't available.
Any backups ?

btw: http://www.bullseyecrosshairs.com/ is still choppy using trunk build 
2002090511 on win-xp pro,1.1ghz,512ram,nvidia geforce2 go

Comment 27

[Jacob Kjome]

I just tried http://www.bullseyecrosshairs.com/ with Mozilla build 2002090608 
on Win2k (sp2sr1) with a PII266 with 128m RAM and Matrox Millenium with 4m RAM 
and it is a bit choppy but not that bad.  It is a bit choppy in IE6 also (a 
little less so than Mozilla) but not all that bad.

I think Mozilla is really touchy about certain video cards because a 1.1ghz 
machine with 512m RAM *should* make Mozilla lightning fast...especially 
compared to my paltry PII266.  Maybe that ought to be investigated?

Jake

Comment 28

[Brandon Streiff [:bstreiff]]

An update on my previous comment (#24): I'm using build 2002090708 now, and
Mozilla no longer freezes up for several seconds on the bullseyecrosshairs.com
site, but there's still momentary choppiness while scrolling. (in particular,
when scrolling quickly, such as with PgUp/PgDn or the mouse wheel)

Comment 29

[Chris Gushue]

Oops, sorry about the missing test case page. A drive died in that system and I
haven't gotten around to fixing it yet.

Uploaded the test page to: http://chris.gushue.net/test.php - and I just noticed
that it isn't AS bad with this build, 2002090511 (win32), but it's still there
and noticable.

Comment 30

[dcone (gone)]

The slowness comes from scrolling a large background image that is scaled, we
have a bug open on that issue.  Our images are kept at the original scale, and
we scale them at render time.  When you have a bunch of images that are scaled
it can really slow things down.  Currently we dont plan on fixing this because
we want the image at the original size for printing, other devices, etc. UPS
would not like the bar codes scaled for example.  The solution would be to cache
not only the original, but any scaled images that are created.

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The solution is to get the scaling done in hardware...

Comment 32

[Ron Thigpen]

Also seeing very slow scrolling, with high CPU usage on this page:

<http://www.axiomaudio.com/faqs.html>

[Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826]

Saving a local copy and browsing with Moz still shows slowness.

Removing background image reference from the body tag of the local copy corrects
the slowness.  The background image ("bg-faq.gif") is a 781 byte GIF file.  It
displays at 13px width and 5500px height.  No image scaling is performed, but it
does tile horizontally across the page.  Reducing browser viewport width causes
the slowness to be reduced proportionally. 

IE5.5 shows some slowness/elevated CPU usage, but not nearly as much.  Also, the
scroll speed is not impacted as heavily.

Comment 33

[Zibi Braniecki [:zbraniecki][:gandalf]]

Cannot reproduce with 20021210.  Nominating to WFM.

Comment 34

[u43589]

Unless the webmaster has modified the site, it seems to work ok now.

WFM

Comment 35

[Wesha]

*** Bug 187559 has been marked as a duplicate of this bug. ***

Comment 36

[José Jeria]

A better example (from dupe):
http://access4less.net/

This almost freezes Mozilla when scrolling. Due to the background image
(http://access4less.net/access4less-750.gif)

Comment 37

[Carine Held]

Confirmed in 1/08/03 runk build, win XP. Attaching minimised test case

Comment 38

[Carine Held]

Attachment: Minimised testcase

Comment 39

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 40

[Kevin McCluskey (gone)]

-> smontagu

Comment 41

[Ruslan Ismailov]

*** Bug 191109 has been marked as a duplicate of this bug. ***

Comment 42

[Markus Hübner]

Using trunk build 2003020308 on winxp pro sp1,1.1ghz,512ram the testcase 
illustrates this problem nicely. Any new findings in the meantime?

Comment 43

[Michael Lefevre]

*** Bug 194046 has been marked as a duplicate of this bug. ***

Comment 44

[Paul Wyskoczka]

ADT: Nominating topembed

Comment 45

[Michael Buckland]

Discussed in top embed bug triage.  Plussing.

Comment 46

[Simon Montagu :smontagu]

The chief problem in the testcase is that the background image is animated, and
for every frame of the animation we are invalidating the whole canvas in
nsImageLoader::RedrawDirtyFrame()

Comment 47

[Scott Carr]

I am seeing this in Mozilla Firebird - Glendale as well.  The URL I am using is:  

http://opinionplugin.sourceforge.net/overview.html

Comment 48

[Simon Montagu :smontagu]

Attachment: An optimization in nsImageWin::ProgressiveDoubleBlit()

When the image is larger than the destination rectangle, we are doing a lot of
unnecessary copying. This patch may help, but I hardly see the problem in the
first place on my system so I'm not sure.

Comment 49

[Dario Baptiste]

I'm getting the same behavior on a page that doesn't appear to have a large
background image:

http://www.svrops.com/

FYI, I'm seeing this in both Moz 1.4b and FB 0.6.  This is on a Win2000 SP3 box.

Comment 50

[Simon Montagu :smontagu]

Attachment: before and after

This shows the windows task manager after a few minutes with attachment 111651 [details]
just sitting in the browser, before and after applying the latest version of
the patch. If I also apply attachment 125358 [details] [diff] [review] from bug 208990, the CPU usage
pretty much flatlines.

Comment 51

[Simon Montagu :smontagu]

Attachment: Patch v.2.

Comment 52

[Ere Maijala (slow)]

While the patch might do the trick, it looks to me that there's rather something
wrong with ProgressiveDoubleBlit(). For me it looks like the biggest difference
between the patch and ProgressiveDoubleBlit() is that PDB uses DC's for masks
and calls BlitImage() which blits the mask and image in two passes using
BitBlt(). Maybe at least some of the mask handling could be done without a DC
and using MaskBlt(). 

That said, is it possible MaskBlt was originally avoided because there were 
problems with it in certain situations? I don't remember, but I'll try to dig up
any reasons.

Comment 53

[Simon Montagu :smontagu]

Yes, eventually I want to change PDB to use MaskBlt() when possible too, though
it may complicate the logic. There is a report in another bug of BitBlt()
showing up in Quantify logs as taking a large proportion of time.

Comment 54

[Ere Maijala (slow)]

Comment on attachment 125976 [details] [diff] [review]
Patch v.2.

Ok, sounds good to me. Now that I think of it, maybe the whole PDB should be
split into different cases. That would make it more readable and easier to
optimize. 

One nit: In SingleBlit, you don't need this test in the end:
+  if (tmpHBitmap) {
+    ::DeleteObject(tmpHBitmap);
+  }

With the check removed,
r=[e-mail]

Comment 55

[Ere Maijala (slow)]

I found one possible problem with using MaskBlt(). Do we need to properly
support Win98/ME? MaskBlt is not supported on these systems.

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

ere: Well, we currently even support Win95
(http://mozilla.org/releases/mozilla1.4rc2/#require). I don't think we should
change that if we can avoid it.

Comment 57

[Ere Maijala (slow)]

Comment on attachment 125976 [details] [diff] [review]
Patch v.2.

Sigh. I guess the use of MaskBlt must be made conditional or avoided then.
Removing r flag :(

Comment 58

[Simon Montagu :smontagu]

Oof, that was sloppy of me. Since I want to leverage MaskBlt() into
ProgressiveDoubleBlit() as well, and since adding another condition into
BlitImage() will make it quite unreadable, this will have to become dependent on
bug 210951.

Comment 59

[Markus Hübner]

[e-mail]: please never again remove Target Milestone settings - just bug 
owners do that!

Comment 60

[timeless]

markus: don't reset bugs to past milestones.
smontagu never set it to 1.5a.

Comment 61

[Jesse Ruderman]

Scrolling pages with large background images sucked even more for a while: 
bug 216430 (was a regression, now fixed).

Comment 62

[Chris Lewicki]

I'm seeing this on Mac OS X 10.3.3 with Mozilla 1.7 RC2. Perhaps it should be
listed as "All"

Even more interesting is that I can click-hold on the scroll bar (with no
movement) and CPU usage will go to 100%.

Comment 63

[Chris Lewicki]

I'm seeing this on Mac OS X 10.3.3 with Mozilla 1.7 RC2. Perhaps it should be
listed as "All".  This happens both with smooth scrolling enabled or not.

Even more interesting is that I can click-hold on the scroll bar (with no
movement) and CPU usage will go to 100%.

Comment 64

[Simon Montagu :smontagu]

Mass reassign my image bugs to [e-mail]

Comment 65

[Amiya Gupta]

Using 0.9, 0.9.1 and 0.9.2 on Win XP SP1, Athlon XP 2000+

Scrolling through the Download and Extension Managers (with enough downloads or
extensions installed) is also slow and jerky, even though I have a 64MB graphics
card.

I assume the problems are related.

Comment 66

[David E. Ross]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910

I have two almost identical test pages.  One shows this problem; the other does
not.  In both cases, the background image is almost the same: GIF, 8.6 KB, style
position:fixed, and fits within a maximized browser window without scaling.  The
difference is that I see the problem on the page where the image has a
transparent background, while the problem goes away when the background is
colored (non-transparent).  

The problem case is at <http://www.rossde.com/test/fixed_bg_image_a.html>.  
The non-problem case is at <http://www.rossde.com/test/fixed_bg_image_b.html>.  

While developing these two test cases, I also determined that -- for both
background images -- the problem goes away if the images have styles that are
position:scroll.  Thus, the problem relates to position:fixed for background
images that themselves have transparent backgrounds.  

Note:  The following bugs seem to report symptoms of this problem -- bug 201307,
bug 222198, and bug 244862.  They might be duplicates.  

Comment 67

[Francois Ingelrest]

I don't know exactly how this is managed and if this can be optimized, but it
seems logical to see a performance decrease when position:fixed is used with
transparent images. Transparent area are 'combined' with other elements on the
page to obtain a 'real' transparency effect. With position:scroll, this is done
once and then the resulting rendered buffer is no longer modified. With
position:fixed, the rendering has to be computed again and again each time the
page is scrolled.

Comment 68

[David E. Ross]

I would think that the background image has to be combined only with other
background elements.  Once a total background is determined, it should not have
to be redetermined as the foreground is scrolled.  Then, whether the image
contains transparency or not would have no effect.  After all, transparency
within a background image is only transparent with respect to the background
color, not with respect to anything in the foreground.  This, of course, applies
to the background of the body.  

When the background is for a block within the body or another block,
redetermination might be needed if the block and the higher level element each
have distinct background images with transparency.  I would think that would
create such confusion for the person viewing the page that it would be rare
unless the page's author were trying to obtain a very special effect (an effect
that might not be possible to obtain except with conditions precisely the same
as the author had when composing the page).  This situaion with multiple layers
of distinct background images might be considered poor (or even pathological)
design of a page.    

On the other hand, the same image -- with the same style specifications -- might
appear in several layers of elements on a page.  This would be done to cause the
image to appear through all layers even when background-color is not
transparent.  Thus, in this comment, I keep referring to "distinct images" and
not merely "images".  

Thus, if the problem were solved only in the case of background for the body,
that might be sufficient.  Of course, it would be better if solved for any case
in which there were only one distinct background image among all superimposed
elements.  Allowing the problem to persist when there are more than one distinct
background image among superimposed elements might be an acceptable penalty for
poor design.  To obtain an effective and efficient fix, it might even be
necessary to allow the problem to persist when the images are all the same and
not distinct.  Here, I am merely speculating because I do not know the design of
the affected component.  

Comment 69

[David E. Ross]

Corrections to my comment #66:

First of all, where I mentioned "position:scroll" and "position:fixed", I meant
"background-attachment: scroll" and "background-attachment: fixed".  

Then, I notice that the problem does indeed exist when the style is
"background-attachment: scroll".  The effect is not as great as with
"background-attachment: fixed", but it can be seen at my
<http://www.rossde.com/index_list.html> if you drag the vertical scroll bar very
quickly.  However, in this case, scrolling with the arrow keys does not scroll
quickly enough to show the problem.  

I hope my observations will help determine the cause of this problem and lead to
a fix.  

Comment 70

[David E. Ross]

Yesterday, I viewed a page affected by this problem on a PC at my local public
library.  The library uses browsers cloned from Internet Explorer, tailored to
certain requirements of the library (e.g., very few user-settable preferences,
all of which revert to default settings on termination).  

The page displayed properly.  The problem did not appear with that IE-based
browser.  The page was my own <http://www.rossde.com/malaprops/malaprops.html>.
 In this case, the background image scrolls.  The problem is not as severe as
with a fixed background image but can still be observed in Mozilla while
dragging the vertical scrollbar.  

The conclusion is that the problem is not inherent in background images with
transparency.  Instead, the problem is likely caused by the sequence in which
components of the display are painted by Mozilla, resulting in the background
being repeatedly repainted (possibly unnecessarily).  IE obviously does it
differently.  

Comment 71

[Mike Kowalski]

*** Bug 275719 has been marked as a duplicate of this bug. ***

Comment 72

[Heath Bates]

I think I might have pin pointed the problem.
It looks like it's an Nvidia issue. I have tested some sites like
http://zeldaclassic.com/ on both ATI and Nvidia based video cards and have also
tried tons of different Forceware drivers. Here is what I have found. 
If you use a program that uses some sort of DirectX or Direct draw then the
problem goes away. For example, go to http://zeldaclassic.com/ with out any
other programs (especially ones that might be using DirectX) running on an
Nvidia based system, you should get the slow scrolling. Now, load up a program
like iTunes or watch a video clip in WMP and then try the site. The slow
scrolling goes away. 
Now, on an ATI video card and with the ATI drivers this is not an issue. Or so I
have seen in my tests.

Comment 73

[David E. Ross]

Re comment #72:  I see this problem on my PC, and I have ATI Rage 128.  

Comment 74

[James Darpinian]

(In reply to comment #72)
> I think I might have pin pointed the problem.
> It looks like it's an Nvidia issue. (...)
> If you use a program that uses some sort of DirectX or Direct draw then the
> problem goes away. 

I can confirm that playing a video in Windows Media player while browsing
http://zeldaclassic.com makes it render a lot faster (on my GeForce 6600 GT). 
Very strange.  Although I wouldn't go so far as to say the problem "goes away".
 Without WMP, it takes over 2.5 seconds to scroll zeldaclassic.com (!!).  With
WMP running, redraws happen more than once per second, at least, but scrolling
is still choppy.  You can open and close WMP to observe the change in rendering
speed without even reloading the page in Mozilla.

Comment 75

[:Gavin Sharp [email: [e-mail]]]

*** Bug 285960 has been marked as a duplicate of this bug. ***

Comment 76

[Dimitrios]

All posted links (including the original url) now work fine for me with FF
20050502 (on a P4-1.8GHz/Geforce MX440/Win2000), with one exception : the
minimized testcase attached first to this bug, ie
https://bugzilla.mozilla.org/attachment.cgi?id=111651

Comment 77

[David E. Ross]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.7) Gecko/20050414
Still a problem.  

Since my prior comments, I have removed the background images from all my
operational Web pages in order to make scrolling smoother for visitors. 
However, the test cases with "background-attachment: fixed" cited in comment #66
still exist and still show the problem for an image with a transparent
background but not for an image with a non-transparent background.  

For a case with "background-attachment: scroll" and a transparent background,
see <URL:http://www.oakparkfoundation.org/>.  

Comment 78

[bstein]

http://www.suspend2.net background image also exhibts this behavior.

Comment 79

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #56)
> ere: Well, we currently even support Win95
> (http://mozilla.org/releases/mozilla1.4rc2/#require). I don't think we should
> change that if we can avoid it.

(In reply to comment #57)
> (From update of attachment 125976 [details] [diff] [review] [edit])
> Sigh. I guess the use of MaskBlt must be made conditional or avoided then.
> Removing r flag :(
> 

Given the rumors I hear of dropping support for older platforms, is the patch worth looking at again?

Comment 80

[David E. Ross]

If older platforms are indeed being abandoned, that still does not mean this is no longer a problem.  Further, the number of users with Windows 98 is almost the same as with either Linux or Macs.  Will the latter two also be abandoned?  

Comment 81

[Ronald Tilby]

URL and Testcase both WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526 Minefield/3.0a1 ID:2006052604

Comment 82

[Wayne Mery (:wsmwk)]

(In reply to comment #79)
> Given the rumors I hear of dropping support for older platforms, is the patch
> worth looking at again?

Even though it no longer crashes (in which case severity should be downgraded to normal or major) isn't it still a valid perf issue on all platforms?
Should the summary reflect the bug also affects scaled images?
Are the problems in the vicinity of comment 58 solveable? 

Note, bug 210951 also has a minused patch.

Comment 83

[Andreas Morawietz]

Please try this page:

http://www.downloadmix.de/dmix/index.asp?DokName=detail.asp&soft_ID=11242

extreme slow scrolling....

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2 ID:2006090703

Comment 84

[Wayne Mery (:wsmwk)]

Comment on attachment 111651 [details]
Minimised testcase

bg image is no longer available -> obsolete

Comment 85

[David E. Ross]

Two test cases are available at <http://www.rossde.com/test/fixed_bg_image_a.html> and <http://www.rossde.com/test/fixed_bg_image_b.html>.  The first of these has a background image whose own background is transparent.  The second has a background image whose own background is white.  

While these two test cases were originally presented in comment #66, which indicates the second is not a problem, I later found (per comment #69) that it was indeed a problem but not as noticeable.  See also my comment #68 and comment #70.  

Now that I have a new PC with Windows XP and 2.66 GHz dual Pentium D processors, the problem is almost unnoticeable.  However, applying greater hardware resources and a new operating system does not constitute a fix to the problem.  

Comment 86

[Andreas Morawietz]

> Now that I have a new PC with Windows XP and 2.66 GHz dual Pentium D
> processors, the problem is almost unnoticeable.  However, applying greater
> hardware resources and a new operating system does not constitute a fix to the
> problem.  

That's right. There are lots of users who use a laptop for surfing... So if pages have 100% cpu all the time, their battery will get empty very very fast. That's bad.

Any date when this bug will be fixed?

Comment 87

[Kurt Weinschenker]

Attachment: Process viewer sample from Mac OS 10.3.9

Noticed what appeared to be a bit of CPU use peaking as well when visiting the Suspend 2 URL.  Tested the Suspend 2 website at http://www.suspend2.net/ with Camino TRUNK nightly 2006102501 (v1.2+), under Mac OS 10.3.9 and ran Activity Monitor's process inspector.

Log is attached.  Hope this helps a bit.

Comment 88

[Wayne Mery (:wsmwk)]

*** Bug 168528 has been marked as a duplicate of this bug. ***

Comment 89

[David E. Ross]

In addition to the bugs I cited at the end of comment #66, this might also be duplicated by bug #244506.  

Comment 90

[Nicolò Chieffo]

I'm an ubuntu linux user and a windwos xp user.
In ubuntu the cpu usage is very high and the scroll is really really choppy (unacceptable)
In XP I don't know if there is hi cpu usage, I only know that scrolling it works without problems

can my bug be considered a cup of this?  bug 392320
if so remove OS=windows 2000 and add something more general!

Comment 91

[JT]

http://www.apple.com/mac/

This site is very choppy, and I can't scroll through it very well

Comment 92

[JT]

In Firefox 3 b4 I think some of these sites are getting better, but below is a site that is unbelievably slow:

http://www.myspace.com/unassuminggrace

Comment 93

[JT]

Attachment: Test Case (MySpace page)

This page is very slow to scroll, and uses the CPU heavily.  In the error console in Firefox 3 Beta 4 this page is giving me a warning saying "Unknown Property 'word-wrap'. Declaration Dropped"

Comment 94

[mmortal03]

Here is another example: http://www.fourtheye.net/?p=1019

Comment 95

[Mantas Mikulėnas (grawity)]

Page: http://www.rossde.com/

scrolling: slower than usually (not much, but difference visible)

CPU: AMD Athlon 64, 2 GHz
RAM: 512 MB
video card: ATI Gigabyte Radeon X600 Pro

Comment 96

[JT]

http://www.macromedia.com/software/flash/about/

scrolling is very slow, and choppy, using 100% of my CPU

Comment 97

[Christian Tanguy]

On my system (Duron 896, 384 Mb, XP, NVIDIA GeForce2 MX 100/200), such problems disappear when I change from 16-bit color depth to 32-bit (the opposite would have been expected, wouldn't it ???)

Comment 98

[lohphat]

16bpp requires palette remapping so for a large image the question is if the palette map is selected once for the entire image or is it remapped for the visible area only. I have no idea if it's the os or the driver itself tasked with the mapping. 

I don't know, these are all speculative on my part. 

Comment 99

[Daniel Gross]

I encounter this problem much more frequently in Firefox 3. In Firefox 2, it happened very rarely.
Hardware:
900Mhz P3, 320MB RAM
ATI Radeon 9200SE 64MB

Comment 100

[Martijn Wargers (dead)]

(In reply to comment #99)
> I encounter this problem much more frequently in Firefox 3. In Firefox 2, it

Yes, known issue :( See bug 361754.

Comment 101

[u294409]

I had this frequently with Radeon 9250 (opensource driver), GeForce 4 MX 420 (nvidia older 96xx driver) and GeForce 6200 (nvidia new driver).

Comment 102

[Roberto Ramirez]

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.

Comment 104

[Jordan Peacock]

I get an uncannily similar issue, tested with WinXP + SP3 and Ubuntu 8.04 using Firefox 3.0.1 and 3.0, respectively.

The site is http://imageserverdemo.rjssoftware.com/imageserver/doc100r?action=init

Contact me for credentials to test it yourself.

Clicking on the folder 'Test folder for Leigh' (bottom left) brings up a table of records. On the left side of each record is a thumbnail, except at full resolution; sometimes 1 or 2 MB per image.

On IE 7 this loads, albeit slowly. On both versions of Firefox it jacks up the CPU and system load and essentially freezes.

This is a bug with our site that we will be addressing sometime soon but it also appears to be a bug in firefox.

Comment 105

[David E. Ross]

Please explain the change of Product to "Core Graveyard".  This might suggest "WontFix" for a bug that is real and should be fixed.  

Also, "Core Graveyard" is supposed to be closed to new bug reports.

Comment 106

[RNicoletto]

Update:
http://imageserverdemo.rjssoftware.com/imageserver/doc100r?action=init ==> No more available
http://www.macromedia.com/software/flash/about/ ==> WFM
http://www.rossde.com/ ==> WFM
http://www.fourtheye.net/?p=1019 ==> WFM
http://www.downloadmix.de/dmix/index.asp?DokName=detail.asp&soft_ID=11242 ==> WFM
http://zeldaclassic.com/ ==> WFM
Test Case (MySpace page) ==> WFM

Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre

Comment 107

[David E. Ross]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6
Windows XP SP3
2.66 GHz dual Pentium D processors
Total Physical Memory	1,024 MB

Testing on <http://rossde.com/test/fixed_bg_image_c.html> (which has a 11 KB PNG background image) by scrolling up and down gives the following:  
memory pages per second jumps to 2700 from less than 100
percent of processor time jumps to 20% from less than 3%

Comment 108

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

David, the retained layers patches that improved this bug landed on trunk (what will be Firefox 4.0). It will not land on the Gecko 1.9.1 or 1.9.2 branches. You can confirm the fix with the soon to be released Firefox 4.0b2.

Comment 109

[Marco Castelluccio [:marco]]

All the testcase WFM under Linux with Firefox 6.0 (Intel Atom).
Firefox uses more CPU than Midori (WebKit), but doesn't use 100% (it arrives at 40%).

Comment 110

[Benoit Girard (:BenWa)]

Closing. This should be fixed by retained layers.