120417 - Mozilla hogs CPU and slows down dramatically on this page

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Sean Harding]

On http://www.weyerhaeuser.com, mozilla (build 2002011008) slows down
dramatically and apparently takes as much CPU as it can get (in FreeBSD). Moving
the mouse cursor is slow and jumpy and everything in the browser responds
sluggishly until the window has been closed. Looking at the site in IE on
windows, there is some kind of animation in the vertical bar on the left. That's
my best guess at the cause.

Comment 1

[R.B.]

Also seen on Linux 2002011608. Actually, it is the X server which uses cca 2/3
of CPU time, and Mozilla 1/3 CPU.

Comment 2

[Andrew Schultz]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020118
I'm also seeing this (about 50/50 between Mozilla and X)

This is a Javascript problem (please move to appropriate component: Javascript
Engine)

The problem is that there are three "animated" images.  The brianiacs at
Weyerhaueser made them move ~0.4 pixels every 0.017 seconds.  This is really
quite stupid.

1) I decreased the load on the XServer by changing the javascript to only "move"
the image when it would actually change its position on the screen.  However,
mozilla took up the slack and it was 80/20 (Mozilla/X).

2) Changing the settings so that it did 1 pixel (explitictly) every x seconds
(where x was increased from 0.017 so that the speed would be the same),
decreased the load a bit more (~70/20) and the images scrolled somewhat faster.

3) There is also a lot of extra work going on in this script that doesn't need
to be there (like taking square roots, ability to do curvature, changing speeds,
etc.) that might slow it down quite a bit.  It seems to be a generic script for
moving things around that is applied to a simple case.

also, this is not a "scrolling" bug (100951 is for scrollbar scrolling problems)

Comment 3

[Asa Dotzler [:asa]]

seems to work  fine in IE. JS performance issue? layout performance issue?

Comment 4

[Andrew Schultz]

Appears to be layout performance.  I disabled the Javascript that actually moves
the images (lines 240 and 241 of thing.js), but left in the rest of the
Javascript.  Mozilla uses 0 or 0.1% of the CPU.

Comment 5

[Andrew Schultz]

the performance is also slow if it is just text (instead of an image) that is
moving.

I also discovered that performance improves as I whittle away at other parts of
the page, even though the moving element is the only thing that is active.  With
most of the other <div> tags disabled, the CPU usage is negligible.  The page
contains 26 div tags.

Comment 6

[Andrew Schultz]

Attachment: minimal testcase

this testcase uses ~40% of my CPU.  Without the empty <div> tags, CPU usage is
negligible.

Comment 7

[Jure Repinc (JLP)]

Mozilla also uses almost all the CPU here when scrolling the page. Mozilla
2002020208 on Windows XP Pro, AMD Athlon 1333 MHz.

Comment 8

[timeless]

the testsuite for this bug is on my system. so the question is can i find the 
bug that references it...

Comment 9

[timeless]

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

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The minimal testcase works fine on my system.  The real page is spending most of
its time in the following stack:

select
...
gdk_flush
gdk_rgb_alloc_scratch_image
gdk_rgb_alloc_scratch
gdk_draw_rgb_image_core
gdk_draw_rgb_image
nsImageGTK::DrawScaled
nsImageGTK::Draw
nsRenderingContextImpl::DrawScaledImage
nsRenderingContextGTK::DrawScaledImage
nsImageFrame::Paint
nsContainerFrame::PaintChild
...


->ImgLib

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think this should be kept as a separate bug, so getting out of a state that's
not supposed to exist ("UNCONFIRMED DUPLICATE").

Comment 12

[Andrew Schultz]

Attachment: original scrolling images replaced by text

this is the original html page with the scrolling images replaced by text. 
this is just as slow as the original.  the solid black background is not an
image.	if Mozilla is spending all its time repainting, then perhaps it is
repainting the whole page.  if so, then ImgLib is not at fault.

Comment 13

[Terri Preston]

I see this behavior on Linux build 2002020222, marking new

Comment 14

[lohphat]

Status update: This page WFM on 2002050504 win32 on win2kpro.

Comment 15

[Markus Hübner]

Quite interesting, when looking at the minimal testcase with the latest trunk 
build (2002052208) I get a CPU usage of about 2%.
But when looking at http://www.weyerhaeuser.com/aboutus/ for example I get 
100% and a bit 'jumping' animation from time to time.

testing workstation has 1.1ghz, 512RAM, win-xp

Comment 16

[Rainer Bielefeld]

WFM with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020531   and RC3

Please have a look on bug 100951 !

Any problmes seen (with other OS) to set this bug FIXED or WFM?

Can we close this bug ?  keywords --> qawanted ?

Comment 17

[José Jeria]

Try this page:
http://www.sausagetools.com/professional/overview.html

(Don't know if I should open a new bug about that one or if it's this bug)
Using build 20020603 Windows 2000.

Comment 18

[Andrew Schultz]

I don't think this is going to make the cut for 1.0...

Comment 19

[Markus Hübner]

Please don't remove those keywords from the triage teams!

Comment 20

[Markus Hübner]

using trunk build 2002120108 on win-xp pro http://www.weyerhaeuser.com/ and
http://www.sausagetools.com/professional/overview.html are fine for me.
Marking WFME ?
 

Comment 21

[Andrew Schultz]

I'm pretty sure this bug is linux-only.  it still occurs with linux trunk 20021210

Comment 22

[Olivier Cahagne]

wfm using FF 20040602 on Linux, CPU goes up to 20-30% (PIII 866MHz) but mouse
isn't jumpy, anyone still seeing this on Linux ?

Comment 23

[Andrew Schultz]

Once the page is loaded (the DHTML animation was the real problem), I'm seeing
CPU usage 0-3%.  My computer is a lot faster than what I was testing with
before, but Mozilla 1.0 on this computer still exhibits the bug (nearly 100% CPU
usage).

resolving WORKSFORME