596491 - Having Flash present on page severely slows down unrelated DOM animation

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Joseph Huckaby]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

This page demonstrates how a tiny, empty, non-animating Flash movie can adversely affect totally unrelated DOM animation going on in Firefox 4 only.  The page starts out showing you some DOM animation achieved with DIVs and a scrolling background.  Note the frame rate display in the top-right corner of the page.  At this point Flash is not present on the page.

Now, click the "Add Flash Movie" button on the bottom of the page.  This will add a small, empty, non-animating Flash movie to the DOM.  Notice your frame rate drops significantly.  My MacBook Pro runs at around 45 fps, then drops to 28 fps with the Flash movie present.

This occurs with ANY Flash movie; I have tried several.  The test page is a good example because it includes an "empty" movie with no frames, animation or code.

While I understand there is going to be a performance hit for any Plugin on the page, this does not occur at all with Firefox 3.6.8 (no noticeable difference in frame rate at all), nor does it happen with any other browser I have tested (Chrome, Safari).  This appears to be something strange with Flash Player on Firefox 4 Beta on Mac.


Reproducible: Always

Steps to Reproduce:
1. Go to http://bowser.macminicolo.net/~jhuckaby/bugs/ff-flash-framerate/
2. Note the framerate in the top-right corner (mine is about 45 fps).
3. Click "Add Flash Movie".
4. Note the framerate has significantly dropped (mine drops to 28 fps).

Actual Results:  
Adding an unrelated, blank, empty, non-animating Flash movie into the DOM severely affects the unrelated DOM animation going on.

Expected Results:  
Since the Flash movie is "empty" and has no animation, frames, code or anything, it should not affect the DOM animation in this way.

This issue does not occur with Firefox 3.6.8, or any other browser I have tested (Chrome, Safari).  It seems to be isolated to Firefox 4 Beta 5 and Beta 6.

I have Mac OS X 10.6.4 and Flash Player 10,1,82,76 (latest stable).

Comment 1

[Boris Zbarsky [:bzbarsky]]

I can definitely reproduce this...  Will try to profile when I get back to having a 32-bit profiling-enabled build.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

What version(s) of Flash are people using?  The latest from Adobe is
10.1 r82.

What versions of OS X are people running?  Joseph is running 10.6.4.
Boris?

If you are running OS X 10.6.4 and either of Adobe's 10.1 Flash
releases (r53 or r82), try changing the following setting, to see if
this is an issue with out-of-process plugins.  Restart the browser
after changing the setting.

Set "dom.ipc.plugins.enabled.flash player.plugin" to 'false' (it
defaults to 'true').

Comment 3

[Joseph Huckaby]

Setting "dom.ipc.plugins.enabled.flash player.plugin" to "false" and restarting doesn't seem to have any affect on the bug for me -- it still slows down to 28 fps with the SWF present.  I have Flash Player 10.1 r82 on OS X 10.6.4.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I'm running Flash 10.1.82.76 (latest), on 10.6.4.

Comment 5

[Benjamin Smedberg]

->bz for profiling

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

See https://bugzilla.mozilla.org/show_bug.cgi?id=596414#c37.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This will conflict with patches in bug 596414, so we should fix this on top of that.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I have a patch to pass false for aRepaint in nsChildView::ConfigureChildren when we reconfigure the NSView for a Cocoa plugin.That saves some painting. My fps drops from 33 to 28, which is less impact than that reported in comment #0, but still significant. I'll look at a profile.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1: Inline ApplyConfiguration into nsChildView::ConfigureChildren

This makes a later patch easier.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 2: Add test to ensure that we don't ask a plugin to paint just because we scrolled it

This test actually passes on trunk because of retained layers --- even if we ask an NSView to repaint in ConfigureChildren, we won't actually ask a Cocoa plugin to paint, because we haven't invalidated the layer it's painted into. But it's a good thing to test anyway.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 3: When we move a plugin's NSView, don't invalidate it if it's a Cocoa-drawing plugin, since we don't paint in that NSView anyway

This builds on the fixes for bug 596414. Since we don't paint in the NSView for a Cocoa plugin, there's no point in invalidating it.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 4: Rename ForcePluginGeometryUpdate to SynchronousPluginGeometryUpdate, and make it do nothing if no plugin geometry update is required

SynchronousPluginGeometryUpdate is a better name; if plugin geometry is already up to date, it doesn't have to do anything. This gets me back to 33fps. (This patch should benefit all platforms.)

Comment 13

[Josh Aas]

Comment on attachment 476663 [details] [diff] [review]
Part 2: Add test to ensure that we don't ask a plugin to paint just because we scrolled it

Nice!

Comment 14

[Timothy Nikkel (:tnikkel)]

Looks like this review request has been missed.

Comment 15

[Mats Palmgren (inactive)]

Comment on attachment 476669 [details] [diff] [review]
Part 4: Rename ForcePluginGeometryUpdate to SynchronousPluginGeometryUpdate, and make it do nothing if no plugin geometry update is required

r=mats (sorry for the delay)

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/366b63f87ace
http://hg.mozilla.org/mozilla-central/rev/b5211d7c2b01
http://hg.mozilla.org/mozilla-central/rev/444c6f0714d1
http://hg.mozilla.org/mozilla-central/rev/38821db8e5c8

Bustage fix:
http://hg.mozilla.org/mozilla-central/rev/c4e5d3de48a6

Disabled test, it's broken. I'll look into this in this bug.
http://hg.mozilla.org/mozilla-central/rev/a8212bca66fb

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Looks like the test fails on non-Mac. Maybe IPC-related.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fixed test

This test passes on Linux with OOPP (and async painting). The problem with the previous test was that windowless plugins on Linux/Windows don't support getEdge, which the test was using.

This test takes an entirely different approach. We scroll the plugin completely into view in one step, then we scroll ten steps of 1px each. We then check that the plugin has painted itself at most twice (see comment in the test). If we paint per-scroll-operation, we're almost certain to paint more than twice even if some of the scroll steps are coalesced due to a slow test machine.

Comment 19

[Harsh86]

Uh, with this bug fixed i now get the opposite behaviour. Adding the flash movie increases the fps by ~10fps. Not a bad thing but, is this the intended behaviour?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No...

What sort of fps numbers are we talking about here? If more than 60, then fps is kinda meaningless so I wouldn't worry about it.

If you're getting less than 60 (without the flash object), and adding the flash object increases it, then please file a bug.

Comment 21

[Joseph Huckaby]

I cannot reproduce Harsh86's behavior.  For me the bug is 100% fixed.  I am getting a consistent 43 FPS with or without the Flash movie on the page.  MacBook Pro 15", 2.4GHz Core i5, 4 GB RAM, today's Minefield build: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre, Flash Player 10,1,85,3

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think Harsh86 agrees the bug is fixed, just for him it's just 200% fixed :-)

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

VERIFIED based on comment #21. Thanks Joseph!