437829 - The new Winstripe APNG throbber eats a lot of CPU cycles

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Kai Liu]

I just installed Firefox 3 on an old laptop, and I noticed that the application startup was significantly slower than what it was in Firefox 2 (I had about 20 saved tabs loading on startup).  I also noticed that loading new pages was taxing the CPU in a way that Firefox 2 never did--even when Firefox was just waiting for the server to respond (this is before receiving any data, so it couldn't have been the page layout/rendering that was eating up cycles)--which made me suspect the new throbber.

So I decided to test this theory:

1) Type chrome://global/skin/icons/loading_16.png into the urlbar
   Firefox CPU: 55-70%

2) Type chrome://global/skin/throbber/Throbber-small.gif into the urlbar
   Firefox CPU: 15-20%

The new APNG throbber is over 3x more expensive than the old GIF throbber.  This probably doesn't amount to much on newer machines, but on this older machine (P3/800), it really bogs things down, especially when there are several of these throbbers spinning at the same time (e.g., when loading saved tabs while restoring a session or loading a folder of bookmarks; in these use cases, Firefox becomes virtually unusable).

I'm not sure what the best solution here would be (or if there even is a good solution).  For me personally, I've swapped out the new throbber and replaced it with the old one, but that's not something that most people would know how to do.

I'm also not sure what exactly is the cause of the inefficiency of this throbber--whether it's something with our APNG implementation or something with the throbber itself (alpha blending isn't cheap).

Comment 1

[Kai Liu]

Attachment: 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.

Comment 2

[Martijn Wargers (dead)]

Attachment: png throbber as background image

Comment 3

[Martijn Wargers (dead)]

Attachment: gif throbber as background image

Comment 4

[Martijn Wargers (dead)]

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

Comment 5

[Justin 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).

Comment 6

[Dão Gottwald [: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.

Comment 7

[Dão Gottwald [: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.

Comment 8

[Kai Liu]

(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

Comment 9

[(not currently active) Ted Mielczarek]

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

Comment 10

[Christoph Langner]

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.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 13

[Martijn Wargers (dead)]

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

Comment 14

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 15

[Joe Drew (not getting mail)]

Attachment: The throbber converted to an APNG file

Comment 16

[Christoph Langner]

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...

Comment 17

[Joe Drew (not getting mail)]

Attachment: 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.

Comment 18

[Christoph Langner]

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...

Comment 19

[Christoph Langner]

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

Comment 20

[Joe Drew (not getting mail)]

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.

Comment 21

[Joe Drew (not getting mail)]

Attachment: a conversion of our current APNG to gif

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

Comment 22

[Christoph Langner]

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

Comment 23

[Joe Drew (not getting mail)]

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

Comment 24

[Joe Drew (not getting mail)]

Attachment: a pretty enormous version of our Windows throbber

Comment 25

[Christoph Langner]

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

Comment 26

[Joe Drew (not getting mail)]

Jeff is our resident expert.

Comment 27

[Martijn Wargers (dead)]

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

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 29

[Ryan Hayle]

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.

Comment 30

[Ruokola Pasi]

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.

Comment 31

[Ruokola Pasi]

Attachment: 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%

Comment 33

[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.

Comment 34

[Max Stepin]

Attachment: optimized throbber, in 24fps

optimized throbber, 24fps version

Comment 35

[Max Stepin]

Attachment: optimized throbber, in 30fps

The same, only faster.

Please, test.

Comment 36

[Justin Dolske [:Dolske]]

How are these "optimized"?

Comment 37

[Max Stepin]

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.

Comment 38

[Justin 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...

Comment 39

[Joe Drew (not getting mail)]

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!)

Comment 40

[Max Stepin]

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

Comment 41

[Vladimir]

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

Comment 42

[Dão Gottwald [:dao]]

Attachment: 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.

Comment 43

[Dão Gottwald [:dao]]

Attachment: APNG-less animation v2

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

Comment 44

[u88484]

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?

Comment 45

[Dão Gottwald [:dao]]

It absolutely doesn't look the same. Here's a tryserver build: https://build.mozilla.org/tryserver-builds/[e-mail]-try-20417565b131/

Comment 46

[Dão Gottwald [:dao]]

Attachment: APNG-less animation v3

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

Comment 47

[Dão Gottwald [: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://build.mozilla.org/tryserver-builds/[e-mail]-try-9da5210166f0

Comment 48

[Mike Beltzner [:beltzner, not reading bugmail]]

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 :(

Comment 49

[Dão Gottwald [: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.

Comment 50

[Dão Gottwald [: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).

Comment 51

[Dão Gottwald [:dao]]

Comment on attachment 399184 [details] [diff] [review]
APNG-less animation v3

I moved this to bug 334697 where it makes sense more directly

Comment 52

[Dão Gottwald [: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.

Comment 53

[Justin 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).

Comment 54

[Martijn Wargers (dead)]

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.

Comment 55

[Justin 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.

Comment 56

[Martijn Wargers (dead)]

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

Comment 57

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 58

[Dão Gottwald [: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.

Comment 59

[Alex Limi (:limi) — Firefox UX Team]

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?

Comment 60

[Max Stepin]

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

Comment 61

[Dão Gottwald [: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.

Comment 62

[Justin Dolske [:Dolske]]

Not actively working at this at the moment.

Comment 63

[Martijn Wargers (dead)]

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

Comment 64

[Dão Gottwald [:dao]]

For the record, bug 334697 would solve this.

Comment 65

[Max Stepin]

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

Or my optimized apng throbber.

Comment 66

[Peter Weilbacher]

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?

Comment 67

[Carlos Alén Silva]

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.

Comment 68

[Martijn Wargers (dead)]

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

Comment 69

[Dão Gottwald [:dao]]

Is that suspicion based on anything?

Comment 70

[Martijn Wargers (dead)]

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