394943 - Pages with many animated images play slowly.

Status: RESOLVED DUPLICATE of bug 418311

(Core Graveyard :: Widget: Mac, defect, P4)

Description

[Justin Dolske [:Dolske]]

On a page with multiple APNGs (or animated GIFs?), the animations play very slowly. It's not due to CPU usage; firebox-bin is only using 20% CPU according to top. [Oddly, that goes *up* to about 28% when the page is in a background tab, not being shown.] The UI seems to remain responsive. All of an animations frames are being shown, it's just that the interframe delays seem to become large (~500ms). If you do a right-click View Image on any animation, it plays at the proper rate by itself.

This is an OS X only bug -- pages play fine on Windows and Linux.

Comment 1

[Justin Dolske [:Dolske]]

(Forgot to note this is trunk... Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007090304 Minefield/3.0a8pre)

Comment 2

[Stuart Parmenter]

this might have to do with how we process events on mac?  not sure.  all of the timer/compositing/etc code is cross-platform.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

For what it's worth, I've noticed the following (I tested with
Minefield and Camino trunk nightlies from the last few days):

1) Performance/speed is much better on this bug's URL if only a few
   animated PNGs are visible at a time.

2) My new appshell patch (bug 395397, first available in 2007-09-20
   trunk nightlies) makes the animations perform much more smoothly on
   Minefield (when all of them are visible in a single page) ... but
   not any faster.  (My patch doesn't make any difference in this
   regard with Camino -- but that's (probably) because Camino was
   already processing Gecko events on demand, instead of a tight
   loop.)

I suspect there's not much we can do about the slowness -- I suspect
that Cocoa is just slower than QuickDraw, or whatever drawing
technology Windows uses.  For certain kinds of operations, recent
Apple JVMs (which all use Cocoa) are also much slower than Apple's
Java 1.3.1 (which used QuickDraw), or than Sun's Windows JVMs:

http://www.segal.org/java/CanvasTable3/index.html

Comment 4

[Steven Michaud [:smichaud] (Retired)]

None of this bug's URL's animated PNGs animate on the 1.8 branch (so
it's not possible to compare animation speed with the 1.8 branch).

Does the 1.8 branch not support animated PNGs?

Is there an analogous demo (of animated GIFs?) that would also work on
the 1.8 branch?

Comment 5

[Steven Michaud [:smichaud] (Retired)]

> [Oddly, that goes *up* to about 28% when the page is in a background
> tab, not being shown.]

I'm not able to reproduce this.

When I switch to a blank tab, CPU usage goes from about 26% to about
11% (on my MacBook Pro).

Comment 6

[Josh Aas]

The 1.8 branch does not support APNG.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I'm setting a priority on this so that it keeps its blocking1.9+ flag.

There are very few pages with so many animations (so the problem is
seldom-encountered), and I'm not sure anything can be done about this.
But the problem, when encountered, is very annoying.  So P4.

Comment 8

[Stuart Parmenter]

Any update on this?  Seems like we really need the event queue to process events more quickly...

Comment 9

[Steven Michaud [:smichaud] (Retired)]

No, I haven't yet had a chance to work on this bug.  I've got a ton of
other bugs to work on first.

By the way, do you know of any pages full of animated GIFs (as opposed
to animated PNGs), so I can do a speed comparison between the trunk
and the 1.8 branch?

Comment 10

[Justin Dolske [:Dolske]]

Attachment: Throbber torture test

This contains two pages, one with 50 16x16 GIF throbbers, and the other with 50 16x16 APNG throbbers.

On OS X [trunk nightly], both the giftest.html and apngtest.html are extremely slow. [This surprised me a bit, because I'm only noticed the problem in the past with APNG.] On my MBP, it takes a second or two for each animation step, and you can watch as each image is advanced frame-by-frame. If you try and resize the window, sometimes they speed up a bit, something they completely stop for a few seconds.

On my Solaris box [with a debug build], both animations seem to play at about normal speed but are choppy, as if frames are being dropped. Oddly, this doesn't always happen... Sometimes mousing over the page or bringing up a context menu will make the animations play smoothly for a few seconds, and then they go back to being choppy.

On Window XP [trunk nightly, in a VM], both the GIF and APNG versions play almost perfectly. There's a very slight roughness / rippling effect, but between there being 50 images and running in a VM it seems more than adequate.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Thanks, Justin!

My results are quite strange:

The speed seems fine (for the animated GIFs) on the 1.8 branch.

On the trunk, both the animated GIFs and the animated PNGs start out
at a reasonable speed, but then quickly (after a few seconds) slow way
down.

I tested on OS X 10.5.2.

Comment 12

[Justin Dolske [:Dolske]]

Ta-da... Latest nightly works flawlessly. Coalesced updates ftl.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

:-)