Closed Bug 437829 Opened 16 years ago Closed 14 years ago

The new Winstripe APNG throbber eats a lot of CPU cycles

Categories

(Firefox :: Theme, defect)

Product:
Firefox
Component:
Theme
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3.7a1

People

(Reporter: kliu, Unassigned)

References

Details

(Keywords: perf, regression)

Attachments

(10 files, 3 obsolete files)

extension to override the new throbber
797 bytes, application/x-xpinstall
Details
png throbber as background image
250 bytes, text/html
Details
gif throbber as background image
262 bytes, text/html
Details
The throbber converted to an APNG file
1.63 KB, image/png
Details
The gif throbber
825 bytes, image/gif
Details
a conversion of our current APNG to gif
3.29 KB, image/gif
Details
a pretty enormous version of our Windows throbber
465.24 KB, image/png
Details
userChrome.css to change back to old throbber
455 bytes, text/css
Details
optimized throbber, in 24fps
3.56 KB, image/png
Details
optimized throbber, in 30fps
3.56 KB, image/png
Details 
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).
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.
Indeed, this seems to make a huge difference in performance.
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).
Flags: blocking-firefox3.1?
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.
(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.
(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

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

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.
OS: Windows XP → All
Hardware: PC → All
Flags: wanted-firefox3.1?
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?
Depends on: 463984
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Why not just return to the gif image? It looks the same.
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.
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...
Attached image 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.
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...
Joe, can you gif me a gif version of "chrome://global/skin/icons/loading_16.png"?
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.
This is a rough conversion of the Linux throbber to gif.
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
So it's probably the combination of frame rate and alpha blending, then.
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
Jeff is our resident expert.
Assignee: nobody → jmuizelaar
Reasking for blocking-firefox3.1? because bug 463984 was marked as invalid.
Flags: blocking-firefox3.1- → blocking-firefox3.1?
Dolske: can you make a lower framerate version of the APNG (still using Alpha channel)
Assignee: jmuizelaar → dolske
Flags: wanted-firefox3.1?
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
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.
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.
Flags: blocking-firefox3.6?
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%
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.
optimized throbber, 24fps version
The same, only faster.

Please, test.
How are these "optimized"?
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.
(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...
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!)
Depends on: 513750
Joe, if you are looking into buffer-clearing stuff, check also image 2 in #433047
What about some static throbber indicating tab is in loading state?
Attached patch APNG-less animation (obsolete) — — Splinter Review 
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.
Attachment #399073 - Flags: ui-review?(beltzner)
Attachment #399073 - Flags: review?(vladimir)
Attached patch APNG-less animation v2 (obsolete) — — Splinter Review 
[progress="67.5"] was wrong, needs to be [progress="62.5"]
Attachment #399073 - Attachment is obsolete: true
Attachment #399076 - Flags: ui-review?(beltzner)
Attachment #399076 - Flags: review?(vladimir)
Attachment #399073 - Flags: ui-review?(beltzner)
Attachment #399073 - Flags: review?(vladimir)
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?
It absolutely doesn't look the same. Here's a tryserver build: https://build.mozilla.org/tryserver-builds/dgottwald@mozilla.com-try-20417565b131/
Attached patch APNG-less animation v3 (obsolete) — — Splinter Review 
Just tweaked the image a bit, otherwise this is still the same patch.
Attachment #399076 - Attachment is obsolete: true
Attachment #399184 - Flags: ui-review?(beltzner)
Attachment #399184 - Flags: review?(vladimir)
Attachment #399076 - Flags: ui-review?(beltzner)
Attachment #399076 - Flags: review?(vladimir)
(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/dgottwald@mozilla.com-try-9da5210166f0
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 :(
Flags: wanted-firefox3.5+
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
(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.
(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 on attachment 399184 [details] [diff] [review]
APNG-less animation v3

I moved this to bug 334697 where it makes sense more directly
Attachment #399184 - Attachment is obsolete: true
Attachment #399184 - Flags: ui-review?(beltzner)
Attachment #399184 - Flags: review?(vladimir)
Depends on: 334697
(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.
(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).
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 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.
You're probably use the Macbook pro for testing then. Probably, you don't see it occuring, because of the speed of that one.
>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.
(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.
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?
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
(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.
Not actively working at this at the moment.
Assignee: dolske → nobody
So perhaps we should be using the gif image again until the performance issue has been solved?
For the record, bug 334697 would solve this.
> So perhaps we should be using the gif image again until the performance issue
> has been solved?

Or my optimized apng throbber.
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?
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
I suspect the new pie-chart throbber is eating a lot of CPU, also.
Is that suspicion based on anything?
No, and I'm not planning on finding out, either.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: