Firefox 3.0 beta 5 40% and 70% CPU AND Xorg 50% and 40%

[spellhower]

Binary package hint: gnome-terminal

Firefox 3.0 beta 5 40% and 70% CPU AND Xorg 50% and 40% of the resourses

ProblemType: Bug
Architecture: i386
Date: Sun Jul 13 21:03:40 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/gnome-terminal
Package: gnome-terminal 2.22.1-0ubuntu2
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=es_CL.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-terminal
Uname: Linux 2.6.24-16-generic i686

[Kliu (kliu)]

Created an attachment (id=324175)
extension to override the new throbber

BTW, this is what I used to restore the old throbber, in case anyone else wanted to do the same. It's just a chrome override.

[Martijn-martijn (martijn-martijn)]

Created an attachment (id=324187)
png throbber as background image

[Martijn-martijn (martijn-martijn)]

Created an attachment (id=324188)
gif throbber as background image

[Martijn-martijn (martijn-martijn)]

Indeed, this seems to make a huge difference in performance.

[Dolske (dolske)]

Windows only? I looked at APNG vs GIF in bug 394943, at the time I only saw perf issues on OS X (which has since been fixed).

[Dao (dao)]

CPU usage for firefox-bin on Linux:

chrome://global/skin/icons/loading_16.png 10%
chrome://global/skin/throbber/Throbber-small.gif 4%

Martijn's background image test also looks slower with the png throbber.

[Dao (dao)]

(In reply to comment #6)
> CPU usage for firefox-bin on Linux:
>
> chrome://global/skin/icons/loading_16.png 10%
> chrome://global/skin/throbber/Throbber-small.gif 4%

Note that there's an overhead of at least one per cent, which makes the png proportionally even more expensive.

[Kliu (kliu)]

(In reply to comment #5)
> Windows only? I looked at APNG vs GIF in bug 394943, at the time I only saw
> perf issues on OS X (which has since been fixed).
>

This is a CPU issue, so it's different than what you saw in bug 394943.

--

Two things changed in the new throbber:
1) GIF -> APNG
2) Simple image -> Image with an alpha channel for anti-aliasing

If it's #1, then there might be a technical fix for this problem. But if it's #2, then there's really not much that could be done about this, as that represents the cost of anti-aliasing. Unfortunately, it looks like that the problem here is indeed #2. I just tested the throbber in bug 326817 comment 3 (an APNG version of the old GIF throbber), and its CPU consumption looked similar to that of the old throbber.

So I think there are three options, none of which are very pretty:
A) Get rid of the throbber anti-aliasing
B) Offer an option to the user (like an "I'm using an old machine" mode
   where throbber anti-aliasing and other expensive things are disabled)
C) Ignore this with the knowledge that as more of these old machines
   are retired, this will matter less

[Ted Mielczarek (ted-mielczarek)]

Has someone run this through a profiler to find out where it's spending all of its time?

[Christoph Langner (chrissss)]

I reported under bug 443962 pretty much the same error

> C) Ignore this with the knowledge that as more of these old machines
> are retired, this will matter less

This shouldn't be an option. I run Firefox3 on a Fujitsu-Siemens Lifebook S-6120 with a Pentium M 1,6Ghz and 1GB Ram. This machine is not outdated and will do a good job for another couple of years.

While firefox is waiting for a website, Xorg takes up to 30% of the cpu time so that the cpu runs with its full 1,6Ghz instead of 600Mhz when idling. The effect is that the fan of my laptop spins like crazy, while the laptop is drawing a simple animation.

[Dao (dao)]

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

[spellhower (cristianandresl)]

Binary package hint: gnome-terminal

Firefox 3.0 beta 5 40% and 70% CPU AND Xorg 50% and 40% of the resourses

ProblemType: Bug
Architecture: i386
Date: Sun Jul 13 21:03:40 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/gnome-terminal
Package: gnome-terminal 2.22.1-0ubuntu2
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=es_CL.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-terminal
Uname: Linux 2.6.24-16-generic i686

[Hew (hew)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, you are not using the most recent version of this package for your Ubuntu release. Please upgrade to the most recent version and let us know if you are still having this issue. Thanks in advance.

[Hew (hew)]

Not gnome-terminal, judging from the report. Assigning to firefox-3.0 for now until more information is received.

[Erik (echakr)]

I KNOW WHY THIS IS HAPPENING

The firefox "Throbber" icon causes 100% CPU load with Xorg when running compiz as pages are loading. You can disable the main throbber which is completely pointless anyway by dragging it off the menu bar using View --> Toolbars --> Customize

But there is no way I know of removing the throbbers from each tab which also eat 100% CPU each

[Hew (hew)]

Thanks for the info. This bug was reported with firefox-3.0 beta 5. Could you please update Ubuntu and let us know what firefox, compiz, and xorg versions you are running to reproduce this issue? If you switch to metacity, does the issue disappear? Thanks in advance.

[Christoph Langner (chrissss)]

This bug is discussed upstream:

http://bugzilla.mozilla.org/show_bug.cgi?id=437829

[Beltzner (beltzner)]

Filed bug 463984 to try and get to the bottom of why APNG decode seems to be so expensive.

Ryan, can you take a profiling run at this and see if the cost can be recovered easily?

[Martijn-martijn (martijn-martijn)]

Why not just return to the gif image? It looks the same.

[Faaborg (faaborg)]

The APNG icon really does look a lot better than the gif (using alpha channel) so ideally we will be able to address the perf issue instead of reverting the image.

[Joe-drew (joe-drew)]

Created an attachment (id=347824)
The throbber converted to an APNG file

[Christoph Langner (chrissss)]

Thanks Joe, here are my results. The "new" Throbber inside Fx3:

chrome://global/skin/icons/loading_16.png:
$ top
[...]
13078 user 20 0 302m 170m 28m R 20.8 17.0 38:09.22 firefox
 5568 root 20 0 261m 41m 9488 S 13.9 4.2 20:32.95 Xorg

The old one

chrome://global/skin/throbber/Throbber-small.gif:
$ top
[...]
 5568 root 20 0 261m 41m 9488 S 6.0 4.2 20:44.18 Xorg
13078 user 20 0 302m 170m 28m S 5.6 17.0 38:24.30 firefox

And the throbber from attachment of Comment #15

$ top
[...]
 5568 root 20 0 261m 41m 9488 S 5.0 4.2 20:48.42 Xorg
13078 user 20 0 302m 170m 28m S 4.6 17.0 38:28.62 firefox

So it's not APNG which causes the load. It's the more elaborated throbber...

[Joe-drew (joe-drew)]

Created an attachment (id=347827)
The gif throbber

Can I get someone whose computer is slow enough to show these performance problems to compare the throbber in gif and APNG format (the two files I've just attached)? Then we can discover whether the problem lies in the throbber we've chosen or the format we've chosen.

[Christoph Langner (chrissss)]

And here again the gif throbber out of comment #17

$ top
[...]
13078 user 20 0 317m 183m 28m R 8.3 18.4 42:34.56 firefox
 5568 root 20 0 267m 50m 10m S 3.6 5.0 23:05.76 Xorg

My guess. It's the throbber, not the format...

[Christoph Langner (chrissss)]

Joe, can you gif me a gif version of "chrome://global/skin/icons/loading_16.png"?

[Joe-drew (joe-drew)]

Some more information: The original throbber was 8 frames, with what looks like 100 ms between each frame. fps = 10.

The Linux throbber is 32 frames, and it has a 35 ms delay between frames. fps = 28.5

The Windows throbber is 24 frames, and has 31.25 ms per frame (more or less). fps = 32

My first inclination is that this is probably caused by simply doing more work, since the fps of the fancier throbbers is higher.

[Joe-drew (joe-drew)]

Created an attachment (id=347853)
a conversion of our current APNG to gif

This is a rough conversion of the Linux throbber to gif.

[Christoph Langner (chrissss)]

Thanks, here are my stats, when i run the picture out of comment #21

$ top
[...]
 5569 root 20 0 242m 20m 9384 R 6.6 2.0 0:16.48 Xorg
 7101 user 20 0 219m 94m 25m S 4.0 9.4 0:29.98 firefox

[Joe-drew (joe-drew)]

So it's probably the combination of frame rate and alpha blending, then.

[Joe-drew (joe-drew)]

Created an attachment (id=348033)
a pretty enormous version of our Windows throbber

[Christoph Langner (chrissss)]

Joe, this last throbber (comment #24) causes heavy load ;)

$ top
[...]
 5573 root 20 0 258m 42m 11m R 41.4 4.2 19:28.87 Xorg
 6329 user 20 0 395m 226m 28m R 34.5 22.6 38:52.99 firefox

[Joe-drew (joe-drew)]

Jeff is our resident expert.

[Martijn-martijn (martijn-martijn)]

Reasking for blocking-firefox3.1? because bug 463984 was marked as invalid.

[Beltzner (beltzner)]

Dolske: can you make a lower framerate version of the APNG (still using Alpha channel)

[Rd+bugzilla (rd+bugzilla)]

I don't know if this is a separate issue or not, but on Linux, using Compiz seems to expose this issue even more. On my dual-core 2.4Ghz laptop, which can't be considered an "old machine", the throbber causes Compiz to use 33%, Firefox 20% and Xorg 16% cpu. All for a simple animation! Something is very wrong here...

I don't like the argument that something shouldn't be fixed because all machines will soon be fast enough to handle it. When you're starting up with 3 or 4 windows, each containing 10-20 tabs, each tab with its own throbber, this becomes a huge issue.

[hackel (hackel)]

Still getting this problem on 8.10 with Firefox 3.0.5+nobinonly-0ubuntu0.8.10.1, Compiz 1:0.7.8-0ubuntu4.1 and Xorg 1:7.4~5ubuntu3. Perhaps Ubuntu needs to replace the default throbber with a simpler one until this issue is resolved.

[Grnhornet (grnhornet)]

Agreed Ryan Hayle eye candy never should be done in expense of performance.

If you like tabs as much me, this problem is very obvious with newer PCs too. I have set browser.tabs.tabMinWidth to 34 and the tab close buttons are disabled. When I continue session with tab bar full of tabs or realod all tabs, the CPU usage will rise up to 100% and will stay there untill most of the tabs are loaded.

If I simply minimize the Firefox window or cover the tab bar with another window (throbbers are not drawn) while the tabs are loading the CPU usage drops near to ~10%

I wonder is Firefox renderin all the tab throbbers separately? The animation runs always at the same pace so Firefox could render the throbber just once and then draw the same throbber image on each tab, but then again I know nothing.

[Grnhornet (grnhornet)]

Created an attachment (id=368043)
userChrome.css to change back to old throbber

The difference significant whean I used this userChrome.css that simply changes throbber images back to old images. The average CPU usage was around 20% while the tabs loaded. With new throbber average CPU usage was over 90%

[Kolyushev Vladimir (k-vvv-ya)]

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

[Dzertanodzh (dzertanodzh)]

There is animated image of same type ("castle nut" revolving circle) in URL bar, when you typing something there and FF searching in visited URL history.

[Newstop (newstop)]

Created an attachment (id=396652)
optimized throbber, in 24fps

optimized throbber, 24fps version

[Newstop (newstop)]

Created an attachment (id=396653)
optimized throbber, in 30fps

The same, only faster.

Please, test.

[Dolske (dolske)]

How are these "optimized"?

[Newstop (newstop)]

In the originals subframes are encoded with dispose_op=background and blend_op=over, despite being full frames 16x16. No need to waste CPU time clearing the background, and then doing proper blending.

My throbbers use dispose_op=none and blend_op=source, they are in grayscale, less pixels are half-transparent, more pixels are fully opaque or fully transparent.

But basically they look the same.

On my system I see less CPU usage, so it would be interesting to know what other people see.

[Dolske (dolske)]

(In reply to comment #37)
> In the originals subframes are encoded with dispose_op=background and
> blend_op=over, despite being full frames 16x16. No need to waste CPU time
> clearing the background, and then doing proper blending.

I don't think that should make any difference. AFAIK we decode after loading into a series of 24bit RGBA surfaces, and just flip between them. So, how the image was encoded should have no effect. The APNG dispose/blend flags should only be used in the initial decode, not as the the animation plays.

> My throbbers use dispose_op=none and blend_op=source, they are in grayscale,
> less pixels are half-transparent, more pixels are fully opaque or fully
> transparent.

I'm not sure grayscale should matter either, as I'm pretty sure it will still get decoded to RGBA surfaces (joe?). I'd assume blending fully opaque/transparent pixels would be faster, but we're still only talking about a handful of pixels per frame...

[Joe-drew (joe-drew)]

We don't just flip between images when they have alpha; we have to do some compositing. It seems like doing a SOURCE would be optimal here, but we still do a clear on source - http://hg.mozilla.org/mozilla-central/file/1b724a06a345/modules/libpr0n/src/imgContainer.cpp#l1454 - I will file a followup bug on whether we can optimize that to OPERATOR_SOURCE. I think yes, but if we're drawing directly to the destination, there might be weirdness.

We always decode to RGB(A). We only get benefits from that if we're decoding RGB-only images, because we can use OPERATOR_SOURCE, which saves a read.

(Incidentally, inspecting imgContainer for commenting on this bug led to me finding bug 513749, which I'm glad to have found!)

[Newstop (newstop)]

Joe, if you are looking into buffer-clearing stuff, check also image 2 in #433047

[Kolyushev Vladimir (k-vvv-ya)]

What about some static throbber indicating tab is in loading state?

[Dao (dao)]

Created an attachment (id=399073)
APNG-less animation

This should be significantly cheaper, and actually more useful than current the stateless animation. With this we could even remove the progress bar from the status bar.

[Dao (dao)]

Created an attachment (id=399076)
APNG-less animation v2

[progress="67.5"] was wrong, needs to be [progress="62.5"]

[Supernova00 (supernova00)]

Dao, if there any changes to the look of the throbber or is it basically the same? Just wondering if you could post a testcase that shows the new APNG-less animation?

[Dao (dao)]

It absolutely doesn't look the same. Here's a tryserver build: https://<email address hidden>/

[Dao (dao)]

Created an attachment (id=399184)
APNG-less animation v3

Just tweaked the image a bit, otherwise this is still the same patch.

[Dao (dao)]

(In reply to comment #46)
> Created an attachment (id=399184) [details]
> APNG-less animation v3
>
> Just tweaked the image a bit, otherwise this is still the same patch.

http://<email address hidden>

[Beltzner (beltzner)]

This won't block unless we can get some compelling numbers about performance improvements. cc'ing shorlander, limi and faaborg (see comment 47) to take a look at the visualization.

I like the idea of progress indication as part of the throbber, though it has some problems due to the way we report progress. For instance, try loading a tinderbox log with this patch and you'll see pretty strange behaviour where it will look like the browser has locked up :(

[Dao (dao)]

(In reply to comment #48)
> I like the idea of progress indication as part of the throbber, though it has
> some problems due to the way we report progress. For instance, try loading a
> tinderbox log with this patch and you'll see pretty strange behaviour where it
> will look like the browser has locked up :(

That's not different from the progress bar at the bottom, though.

[Dao (dao)]

(In reply to comment #49)
> (In reply to comment #48)
> > I like the idea of progress indication as part of the throbber, though it has
> > some problems due to the way we report progress. For instance, try loading a
> > tinderbox log with this patch and you'll see pretty strange behaviour where it
> > will look like the browser has locked up :(
>
> That's not different from the progress bar at the bottom, though.

To clarify... I didn't mean to say that said behavior is generally correct, it's just not a bug in the code that I touched here (but somewhere deeper in mozilla land).

[Dao (dao)]

(From update of attachment 399184)
I moved this to bug 334697 where it makes sense more directly

[Dao (dao)]

(In reply to comment #48)
> This won't block unless we can get some compelling numbers about performance
> improvements.

Regarding the performance: This should kill all the APNG overhead, since it's not an animated image anymore. Instead of 24 or more frames per second, there would only be half a dozen style changes that move a static PNG around.

[Dolske (dolske)]

(In reply to comment #42)
> Created an attachment (id=399073) [details]
> APNG-less animation

This really isn't the right bug to be doing something like this in... File a new bug and take it there?

FWIW, from the history here it's not clear to me that the APNG CPU usage affects more than a small number of users. Something that would be nice to fix, but I don't think it needs to drive a redesign of the throbber design. (Maybe we want to do that anyway, fixing this as side effect, though).

[Martijn-martijn (martijn-martijn)]

Yes, it affects all users. The thing is, if you have a fast cpu, you won't notice, that the apng uses slightly more cpu power.

[Dolske (dolske)]

Comment 10 and 29 both say they see a problem on reasonably fast systems. IIRC, both joe and I were unable to reproduce the problem on systems we had at hand. The Fennec folks are also using an APNG throbber, so I'd be surprised if it had escaped their profiling.

[Martijn-martijn (martijn-martijn)]

You're probably use the Macbook pro for testing then. Probably, you don't see it occuring, because of the speed of that one.

[Faaborg (faaborg)]

>That's not different from the progress bar at the bottom, though.

OS X and subsequently Vista solve this feedback problem by having their progress bars visually pulse even if they are remaining still. (which we don't currently pick up since we don't have widget animation yet). But that's the best solution to providing the user with feedback+progress. Just feedback or just progress isn't as good as the combination of both.

[Dao (dao)]

(In reply to comment #57)
> >That's not different from the progress bar at the bottom, though.
>
> OS X and subsequently Vista solve this feedback problem by having their
> progress bars visually pulse even if they are remaining still. (which we don't
> currently pick up since we don't have widget animation yet). But that's the
> best solution to providing the user with feedback+progress. Just feedback or
> just progress isn't as good as the combination of both.

I've made initial state pulse in bug 334697.

[Limi-mozilla (limi-mozilla)]

My recommendation would be to defer this to 3.7, since we're giving the progress/activity a new treatment there. I don't think this is likely to make it for 3.6 at this point anyway?

[Newstop (newstop)]

Meanwhile you could try my apng throbbers (comments #35 or #36) as a first step.
They take less CPU, and look the same, so it's win-win, even if only until 3.7

[Dao (dao)]

(In reply to comment #59)
> My recommendation would be to defer this to 3.7, since we're giving the
> progress/activity a new treatment there. I don't think this is likely to make
> it for 3.6 at this point anyway?

This is now in bug 334697, and I don't see a reason why it shouldn't make 3.6.

[Dolske (dolske)]

Not actively working at this at the moment.

[Martijn-martijn (martijn-martijn)]

So perhaps we should be using the gif image again until the performance issue has been solved?

[Dao (dao)]

For the record, bug 334697 would solve this.

[Newstop (newstop)]

> So perhaps we should be using the gif image again until the performance issue
> has been solved?

Or my optimized apng throbber.

[pmow (pmow)]

All this discussion with "should", "may", "would", "or" is pretty pointless.

Who is deciding which way to go and what data does he/she need to come to a decision?

[Carlos-alen (carlos-alen)]

Either optimized APNG throbber or old GIF throbber seem to solve the problem, so I also make mine the question in comment 66. Please, somebody decide. This is an issue that is pretty easy to solve and could have a visible benefit, specially for laptop and slow machines users.

[Martijn-martijn (martijn-martijn)]

I suspect the new pie-chart throbber is eating a lot of CPU, also.

[Dao (dao)]

Is that suspicion based on anything?

[Martijn-martijn (martijn-martijn)]

No, and I'm not planning on finding out, either.