Closed Bug 1314467 Opened 5 years ago Closed 4 years ago

Huge performance regression when Flash object is opened in many tabs


(Core :: Plug-ins, defect)

52 Branch
Windows 10
Not set



Tracking Status
firefox49 --- wontfix
firefox-esr45 --- unaffected
firefox50 --- disabled
firefox51 + disabled
firefox52 + disabled
firefox53 + disabled
firefox54 --- affected


(Reporter: alice0775, Unassigned)



(Keywords: perf, qawanted, regression, Whiteboard: [parity-chrome] [parity-edge][qawanted , help gecko profile])


(1 file)

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
Summary: Browser becomes unresponsive when Flash object is opened in two tabs → Browser becomes unresponsive when Flash object is opened in many tabs
[Tracking Requested - why for this release]: unable to use browser whwn multiple Flash(incl ads) in many tabs

Regression window:

Regressed by: bug 1229961 on trunk
Blocks: 1229961
Severity: normal → major
Keywords: regression
Summary: Browser becomes unresponsive when Flash object is opened in many tabs → Huge performance regression when Flash object is opened in many tabs
Setting dom.ipc.plugins.asyncdrawing.enabled = false fixes the unresponsive and slowness on Nightly52.01 and Autora51.0a2.
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(
Severity: major → critical
Logging of using Gecko Profiler is not successful, because cleopatra indicates "Retrieving profile" forever.
Component: Layout → Plug-ins
Keywords: qawanted
Whiteboard: [parity-chrome] [parity-edge] → [parity-chrome] [parity-edge][qawanted , help gecko profile]
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.
Flags: needinfo?(twalker)
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.
Flags: needinfo?(twalker)
bsmedberg's guess was good, we are receiving extra frames. looking at that now.
Attached patch debug patchSplinter Review
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.

Flags: needinfo?(mtalistu)
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.
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.
Track 51+/52+ as performance regression related to flash.
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.
Flags: needinfo?(mtalistu)
This is related to asyncdrawing, which is not enabled in beta.  Marking disabled in 51.
Tracking 53+ for this flash perf regression.
Jim, is this still a concern for 52 or 53 (no asyncdrawing on non-Nightly)? Or even 54 given comment 13?
Flags: needinfo?(jmathies)
fixed based on comment 13 and local testing.
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.