642257 - Flash video in background tab degrades FF rendering performance

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[The 8472]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110316 Firefox/4.0b13pre
Build Identifier: 

Having a flash video open (even when it's paused) in a background tab significantly increases the time it takes to render roc's accelerated scrolling test:
http://people.mozilla.org/~roc/scrolling-boxes.html

Zapping the plugin-container returns performance to previous values.



Reproducible: Always

Steps to Reproduce:
1. Open a youtube video
2. Pause the video
3. Open http://people.mozilla.org/~roc/scrolling-boxes.html in a new tab and let the test fish
4. kill plugin-container.exe or close the youtube page
5. repeat step 3



* using flash 10.3 beta (issue also occurred with 10.2)
* hw acceleration is on (D3D10)

Comment 1

[Benjamin Smedberg]

Can you indicate the particular Flash video you see this with? There are huge differences between various types of Flash (windowed/windowless-opaque/windowless-transparent).

Comment 2

[The 8472]

It happens with both fullscreen and non-fulscreen youtube videos. That would be windowed and windowless-something?

Comment 3

[Benjamin Smedberg]

A youtube video can't be fullscreen when you run scrolling-boxes, right? Can you link to a specific page? It unfortunately matters, just so we can all test the same thing.

Comment 4

[The 8472]

>A youtube video can't be fullscreen when you run scrolling-boxes, right?
Since 10.2/10.3 flash opens fullscreen in a separate window, so you can switch back to firefox and run scrollingboxes while the flash fullscreen window is still open.

>Can you link to a specific page?
Sure. http://www.youtube.com/watch?v=45NJerPFls4

Comment 5

[Benjamin Smedberg]

That's a Flash bug, we think, but not relevant to the issue here. I'm guessing that we're doing D3D readback on scrolling-boxes, and maybe even sending the plugin background updates, even though we don't actually need to.

Comment 6

[The 8472]

>I'm guessing that we're doing D3D readback on scrolling-boxes
I just tested with HW acceleration off and the issue remains.

Comment 7

[The 8472]

I only mentioned this on IRC and forgot to put it in the report:
w/  flash: ~19 seconds
w/o flash: < 4 seconds

Comment 8

[Benjamin Smedberg]

There is almost no IPC traffic during this case (network data being delivered once a second or so).

Did you turn Flash acceleration off, or Firefox acceleration, or both?

Comment 9

[The 8472]

> There is almost no IPC traffic during this case (network data being delivered
> once a second or so).
Yeah, IPC off is the first thing i tried anyway and the problem was still there
 
> Did you turn Flash acceleration off, or Firefox acceleration, or both?
FF acceleration, i didn't find the flash acceleration setting in 10.3

Comment 10

[The 8472]

Ok, now i found it, the issue still remains even with flash HW acceleration and FF hardware acceleration both being disabled.

Comment 11

[The 8472]

Another observation:
without flash: < 4s
with flash video in normal mode: 8s
with flash video in normal mode -> fullscreen: 8s
with flash video in "expanded mode" (the widescreen button on youtube): 19s
with flash video in "expanded mode" -> fullscreen: 19s

So the slowdown might depend on the surface area occupied by the plugin on the website, even when the actual surface (flash fullscreen window) is larger

Comment 12

[The 8472]

After toying around with the CSS a bit i was able to pin the slowdown to those rules:
border-radius: 2px 2px 2px 2px;
box-shadow: 0 0 5px #888888;

Disabling rounded borders yields a speedup from 19s to 4s, then disabling the shadows from 4s to 2s. So i guess rounded borders are the lion's share here.

So having flash *anywhere* in the browser + rounded borders triggers some slow path?

Comment 13

[Benjamin Smedberg]

Where are those CSS rules? In roc's testcase, or somewhere on youtube? The point is that when youtube is in the background, it ought to have little or no effect on multicore machines at least: Flash might run stuff in its process, but that shouldn't effect Firefox CPU usage or event latency at all. Something is very strange here.

Comment 14

[The 8472]

>Where are those CSS rules? In roc's testcase, or somewhere on youtube?
in roc's testcase

>but that shouldn't effect Firefox CPU usage or event latency at all.
I think it's not about flash doing anything, it's about a plugin surface being present and triggering something in the renderer/accelerated layers/whatever to take a slow path when using rounded corners.

Comment 15

[Timothy Nikkel (:tnikkel)]

(In reply to comment #12)
> After toying around with the CSS a bit i was able to pin the slowdown to those
> rules:
> border-radius: 2px 2px 2px 2px;
> box-shadow: 0 0 5px #888888;

Those are the rules that slowdown roc's testcase in general, so I don't think it tells us much that removing them in this situation speeds things up as that is what we would expect.

Comment 16

[The 8472]

You're right. I forgot to also redo the baseline measurement with those two off. After increasing the number of visible spans on the page and running the test again with and without an embedded flash element in a background tab there's still a significant performance difference.

So ignore what I said in comments 12 and 14.

Comment 17

[Phoenix]

Just tested latest nightly, with Youtube opened in other tab I get 13835 ms and 7047 ms without it respectively.
Build: Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111209 Firefox/11.0a1
Also, on 8.0.1 numbers are lower, 11472 ms with and 6188 without
Build: Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

Comment 18

[Christian Ascheberg]

I can also confirm this problem.
The scrolling-boxes testcase runs in about 8 seconds w/o flash.
But when there is a youtube flash video in the background (not running), I can barely get the testcase to run without crashing the browser. Actually, it takes about 8 seconds for every single scrolling step.

Could someone re-run this to check if the problem has gotten worse?

I am using the 2012-10-15 nightly build and Flash 11.4 r402 on Windows7.

Comment 19

[Benjamin Smedberg]

Taras, have you got someone who can help investigate this? Flash in a background tab really shouldn't affect foreground perf.

Comment 20

[Timothy Nikkel (:tnikkel)]

I've read that Flash running puts Windows into high precision timer mode, a possible explanation.

Comment 21

[(dormant account)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #19)
> Taras, have you got someone who can help investigate this? Flash in a
> background tab really shouldn't affect foreground perf.

youtube does. I just tested this about telemetry 'animate' button. When you have a youtube video downloading it causes cache contention on the main thread.

Please retest to see if youtube still causes jank once the video is downloaded, otherwise this is a DUP of bug 717761

Comment 22

[Christian Ascheberg]

The testcase is still slow, even if the video is fully buffered. It does not only happen on youtube. I checked with 2 videos < 1 minute on different sites.
I can reproduce it with a adobe reader plugin in a background tab as well.

Comment 23

[(dormant account)]

(In reply to Christian Ascheberg from comment #22)
> The testcase is still slow, even if the video is fully buffered. It does not
> only happen on youtube. I checked with 2 videos < 1 minute on different
> sites.
> I can reproduce it with a adobe reader plugin in a background tab as well.

What Firefox/OS versions?

Comment 24

[Christian Ascheberg]

(In reply to Taras Glek (:taras) from comment #23)
> (In reply to Christian Ascheberg from comment #22)
> > The testcase is still slow, even if the video is fully buffered. It does not
> > only happen on youtube. I checked with 2 videos < 1 minute on different
> > sites.
> > I can reproduce it with a adobe reader plugin in a background tab as well.
> 
> What Firefox/OS versions?

As mentioned above, I am using nightly (so currently 2012-10-16), Flash 11.4.402.287, Adobe Reader 10.1.4.38, Windows7 (64bit).

Comment 25

[(dormant account)]

(In reply to Christian Ascheberg from comment #22)
> The testcase is still slow, even if the video is fully buffered. It does not
> only happen on youtube. I checked with 2 videos < 1 minute on different
> sites.
> I can reproduce it with a adobe reader plugin in a background tab as well.

I can't reproduce this, can you try to record the jank with the gecko profiler https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler

P3 until we can confirm this.

Comment 26

[Christian Ascheberg]

I don't know anything about the profiler, so tell me if the results are helpful (or what else I should do).

What I did here:
opened this bug page, opened a 30 sec youtube video, waited until video was buffered, opened and switched to the URL given in this bug (scrolling-boxes)
result: every few seconds Windows tells me that Firefox is not responding anymore, so I waited a bit, then killed the flash process, after some more seconds I could use Firefox again
http://people.mozilla.com/~bgirard/cleopatra/?report=166e09166157e029a6146897f087443f29f3ba3b

Two more reports with more or less similar actions:
http://people.mozilla.com/~bgirard/cleopatra/?report=979735a9ef24ceec4c8619129ef56d84fd3f4c76
http://people.mozilla.com/~bgirard/cleopatra/?report=53002da2de2358dc0e4a5c76ff2d283aa6799491

Comment 27

[Timothy Nikkel (:tnikkel)]

Looks like when we are computing visibility for plugin geometry we get bogged down because we have to use accurate visible regions and not simplify them.

We have a fast path for when there aren't any plugins at all. Perhaps we could check if the display list has any object items and skip an unnecessary and costly compute visibility pass if there are none.

Comment 28

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

Yes, we could do that, and should do that!

Comment 29

[Timothy Nikkel (:tnikkel)]

Got a patch already, so stealing this.

Comment 30

[Timothy Nikkel (:tnikkel)]

Attachment: patch

I haven't looked over the new way of doing plugin geometry, but this seems right.

Comment 31

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

Comment on attachment 672643 [details] [diff] [review]
patch

Review of attachment 672643 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/base/nsPresContext.cpp
@@ +2564,5 @@
>    if (!rootFrame) {
>      return;
>    }
>  
> +  if (aBuilder->ContainsPluginItem()) {

Make this "if (aBuilder->ContainsPluginItem() && rootFrame)" and remove the earlier check. It was slightly wrong to return early in that case without calling InitApplyPluginGeometryTimer.

Comment 32

[Timothy Nikkel (:tnikkel)]

https://tbpl.mozilla.org/?tree=Try&rev=477cfa96d394

Comment 33

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/87df09bc5e8e

Comment 34

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/87df09bc5e8e

Comment 35

[Christian Ascheberg]

A quick check on my system confirmed that the problem is gone. Thanks for fixing it this promptly.

Comment 36

[Timothy Nikkel (:tnikkel)]

Comment on attachment 672643 [details] [diff] [review]
patch

This is a safe patch that should give us some small performance wins.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): been around for a while
User impact if declined: we get a small perf win with this patch
Testing completed (on m-c, etc.): been on m-c for about 3 weeks
Risk to taking this patch (and alternatives if risky): not risky
String or UUID changes made by this patch: none

Comment 37

[bhavana bajaj [:bajaj]]

Comment on attachment 672643 [details] [diff] [review]
patch

Approving on aurora . low risk patch for a perf win :)

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/626e845bf260

Comment 39

[Morar Mihai]

(In reply to The 8472 from comment #0)
> User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre)
> Gecko/20110316 Firefox/4.0b13pre
> Build Identifier: 
> 
> Having a flash video open (even when it's paused) in a background tab
> significantly increases the time it takes to render roc's accelerated
> scrolling test:
> http://people.mozilla.org/~roc/scrolling-boxes.html

> It looks like you were right. I'd tested on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110316 Firefox/4.0b13pre and it really takes longer while youtube video is paused.

I'd also tested this issue on: 
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20121205 Firefox/20.0 (20121205030759)  Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0 (20121128060531)

For theese 2 builds the difference between running scrolling test with and without youtube video paused is about some milliseconds. So i think this bug should be Verified for FF18. Someone with permission please set flag.
>  
>

Comment 40

[Paul Silaghi, QA [:pauly]]

Verified fixed FF 18b2, Aurora 19.0a2 (2012-12-05) Win 7.