1314467 - Huge performance regression when Flash object is opened in many tabs

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Alice0775 White]

Chrome works fine.

Steps To Reproduce:
1. Open html ( attachment 8806528 [details] )
2. Duplicate the tab in 5 tabs by clicking reload button
   --- Observe, Slow to open tabs, Slow animation, Spinner spin
3. Repeat switch tabs 5-10 times
   --- Observe, Spinner spin
4. Quit browser
   --- Observe, It takes few seconds

Comment 1

[Alice0775 White]

[Tracking Requested - why for this release]: unable to use browser whwn multiple Flash(incl ads) in many tabs

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=02c69f4f896255189ce2f9f4e0d875e383bcfbd7&tochange=a1bd47d76f71162534090485acc57866dcd55eef

Regressed by: bug 1229961 on trunk

Comment 2

[Alice0775 White]

Setting dom.ipc.plugins.asyncdrawing.enabled = false fixes the unresponsive and slowness on Nightly52.01 and Autora51.0a2.

Comment 3

[Alice0775 White]

Steps To Reproduce:
1. Open html ( attachment 8806528 [details] ) in 5 tabs
   Observe [1]
2. Wait for 1-2 min
3. Attempt to switch tabs, Open any webpage in a new tab
   Observe  [1] [2] [3] [4]


Actual Results:
[1] Huge performance regression. The flash animation becomes super slow motion.
[2] When switch tabs, Spinner is spinning for a long period(1+ min).
[3] High CPU usage (firefox.exe 25-40%) while spinner is spinning.
[4] Trying open any webpage in a new tab (especially while spinner is spinning), Spinner is also spinning for a long period.

I think this is very bad user experience. It should not release the browser without fix this.
This problem has been reported in Japanese bulletin boards(2ch.net).

Comment 4

[Alice0775 White]

Logging of using Gecko Profiler is not successful, because cleopatra indicates "Retrieving profile" forever.

Comment 5

[Jim Mathies [:jimm]]

Tracy, can you do a comparison here between non async and asyn perf. I loaded this up into five tabs and let it sit for a bit. I'm not seeing all the issues alice is describing. 

Note we're looking for differences here between the two mode settings. I don't care if this flash applet is generally slow regardless.

Comment 6

[Benjamin Smedberg]

One  thing to check explicitly here is whether Flash is sending us frames for instances which are not visible: either scrolled off the screen or in a background tab. In either case, we should be informing Flash that the instance is inactive, and Flash should not be sending us frame updates for those instances. If it *is* sending us frames, that will definitely cause performance problems.

Comment 7

[Jim Mathies [:jimm]]

bsmedberg's guess was good, we are receiving extra frames. looking at that now.

Comment 8

[Jim Mathies [:jimm]]

Attachment: debug patch

Comment 9

[Jim Mathies [:jimm]]

Hey Matt,

We are seeing a problem with async painting where the flash plugin continues to generate frames for plugins that are out of view or embedded in background tabs. Firefox is sending proper clip rect [1] information in its set window calls, and this appears to be ignored.

In the debug patch I've posted I've introduced an experiment that sets the width and height of the area we expect flash to paint too to zero when an applet isn't visible. This fixes the recurring paint problem.

Would you mind taking a look? I'm hoping this should be pretty easy to fix on adobe's side.

[1] http://searchfox.org/mozilla-central/rev/f5c9e9a249637c9abd88754c8963ecb3838475cb/dom/plugins/base/npapi.h#509

Comment 10

[Tracy Walker [:tracy]]

I'm not seeing the issues Alice reports here with slow animations, spinners and such.  

What I do observe to be different between dom.ipc.plugins.asyncdrawing.enabled enabled vs disabled is described as follows:

with dom.ipc.plugins.asyncdrawing.enabled = true:
The animations are all good except the girl playing hopscotch; She starts out on the right and the background around the hopscrotch court is green as expected.  But, as she hops to the left, rectangles of black background are painted until it fills the particular animation space. It's just background black,  the hopscotch court remains visible as does the girl.

dom.ipc.plugins.asyncdrawing.enabled = false
all the animations leave remnants behind until painted over again.  The hoola-hoop pn the left leaves behind yellow bits as it animates back and forth.  The basketball players hair leaves remnants behind as his head bobs up and down.  The hopscotch girls hair also does same.  The only animation not affected is the smaller girl with blue hoola-hoop.

Comment 11

[Alice0775 White]

FYI, 
Nightly 64bit: Not seeing spinner spinning. But seeing slowness(opened 3+ tabs)
Nightly 32bit: seeing spinner spinning. And seeing slowness(opened 4+ tabs)

My PC is 7 years old.
CPU : Core2Quad @2.5GHz (I always set Power Save mode to 2.0GHz)
GPU : AMD HD6450

Probably, It may depend on number of CPU CORE and/or GPU spec.


BTW, The black thing is Bug 1312242.

Comment 12

[Gerry Chang [:gchang]]

Track 51+/52+ as performance regression related to flash.

Comment 13

[mtalistu]

I have made the suggested fix on the Flash Player plugin side. If the NPWindow's clipRect is {0,0,0,0}, we will change the NPWindow's x/y/width/height to {0,0,0,0} to prevent Flash Player from sending any frames to the browser. This change should be available in next week's beta release of Flash Player 24.0. If it looks good, it should ship in our December Flash Player 24.0 release.

Comment 14

[Julien Cristau [:jcristau]]

This is related to asyncdrawing, which is not enabled in beta.  Marking disabled in 51.

Comment 15

[Marcia Knous [:marcia]]

Tracking 53+ for this flash perf regression.

Comment 16

[Andrew Overholt [:overholt]]

Jim, is this still a concern for 52 or 53 (no asyncdrawing on non-Nightly)? Or even 54 given comment 13?

Comment 17

[Jim Mathies [:jimm]]

fixed based on comment 13 and local testing.