141801 - Performance problem with JavaScript-animated background

Status: NEW

(Core :: Layout, defect, P3)

Description

[Cesar Eduardo Barros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020426
BuildID:    2002042610

Opening the page makes the X server use about 70% of CPU while Mozilla uses
about 30% CPU. Closing the page makes everything go back to normal. This seems
to be caused by the animated background.

Looking at the code, it seems to use document.body.style.backgroundPosition to
move the background in a tight setTimeout() loop -- with the timeout set to
zero. (the function they use is called moveback()).

Reproducible: Always
Steps to Reproduce:
1. Start top in a xterm
2. Open the page

Actual Results:  The X server uses 70% while Mozilla uses 30%. This happens even
with Mozilla not visible (the percentages probably change when it's visible).
Everything slows a bit (the computer "feels" half the speed for me) since X is
niced to -10.

Expected Results:  No slowdown. Only a bit more CPU usage. No extra CPU usage
when the tab or the window isn't visible.

The problem seems to be the moving of the background in a setTimeout("",0) loop.
Mozilla shouldn't update the screen more than X times per second (configurable),
since after some point extra updates per second aren't noticeable anymore.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

If setTimeout("",0) is the problem, see bug 123273

Comment 2

[Boris Zbarsky [:bzbarsky]]

sounds like a dup of other "painting when not visible" bugs....

Comment 3

[Cesar Eduardo Barros]

re comment 1:

This is not bug 123273, since it's X that's eating most of the CPU, not Mozilla
(which just grabs the remaining 30%).

re comment 2:

Nope, since the CPU usage is high even if it's visible. That's the problem here.
The "even when not visible" part will be fixed by these other bugs...

Comment 4

[Laura Krietemeyer]

Changing QA Contact

Comment 5

[Moied]

confirmed using branch build 20020509 on linux

Comment 6

[Boris Zbarsky [:bzbarsky]]

Cesar, we peg the timeout at at least 10ms now.  Any delay much higher than this
_would_ be noticeable by people, so we can't really just drop paints on the floor...

In any case, the testcase uses about 40% CPU for Mozilla and 0% for X here.  A
profile shows us spending most of our time in style reresolution, which makes sense.

Could you possibly retest with a recent build and let me know how it acts on
your end?

Comment 7

[Cesar Eduardo Barros]

Changing URL to point to Internet Archive copy of original page; the page has changed since, and the current page does not show the problem.

Comment 8

[Cesar Eduardo Barros]

Copy of my answer to an email query:

> <https://bugzilla.mozilla.org/show_bug.cgi?id=141801>
> 
> Cesar,
> do you still see the problem using current version of the product?

Yes, I still do (with "Mozilla/5.0 (X11; U; Linux x86_64; pt-BR; rv:1.8.1.1) Gecko/20060601 Firefox/2.0.0.1 (Ubuntu-edgy)" now). However, I had to get an old version of the page from the Internet Archive; the page has changed too much since. I updated the URL in the bug report to point to the archived copy of the page, and will see if I can make a reduced testcase.

Comment 9

[Boris Zbarsky [:bzbarsky]]

For what it's worth, a profile with a current build shows us spending half our time in cairo painting slowness (text and underlines) and half our time reresolving style on everything on the page (since the body's style context is changing).

Comment 10

[Boris Zbarsky [:bzbarsky]]

It would still be good to have a testcase attached directly to the bug.

Comment 11

[Cesar Eduardo Barros]

Attachment: Reduced testcase

Reduced testcase; removed all external dependencies.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Should reprofile once new textframe lands.

Comment 13

[Guilherme Lima]

Reduced testcase still uses a full single core of my CPU, using lastest nightly (Gecko/20110114 Firefox/4.0b10pre).
IE8 and Chrome 8 have the same problem, at least.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Over here it's using about 50% of CPU.  Until I put it in a background tab; then it goes down to 20 (thanks to refresh driver throttling).

Imo, this bug is basically fixed as filed....

Comment 15

[Guilherme Lima]

Something got broken in Firefox or it got super fast on this testcase? Because it uses 0% of CPU and Chrome uses almost 100% of all cores.
This is super fixed, I think.

Comment 16

[Boris Zbarsky [:bzbarsky]]

It's possible that DLBI affected this testcase.

Comment 17

[Guilherme Lima]

I'm using Firefox 16 (beta)

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Corrected testcase

Testcase is invalid as it did not specify the css units; chrome let "N N" be equivalent to "Npx Npx".  Corrected.  Note that referencing a non-existent background object in a setTimeout(...,0) loop may not be a good test...
If you save and add a background.gif file, FF and Chrome both get very busy... The settimeout lower limit is in play here.