Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Flash video in background tab degrades FF rendering performance

VERIFIED FIXED in Firefox 18

Status

()

Core
Plug-ins
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: The 8472, Assigned: tnikkel)

Tracking

Trunk
mozilla19
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18 verified, firefox19 verified)

Details

(Whiteboard: [Snappy:P3][sps], URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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)
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).
(Reporter)

Comment 2

6 years ago
It happens with both fullscreen and non-fulscreen youtube videos. That would be windowed and windowless-something?
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.
(Reporter)

Comment 4

6 years ago
>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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

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

Comment 7

6 years ago
I only mentioned this on IRC and forgot to put it in the report:
w/  flash: ~19 seconds
w/o flash: < 4 seconds
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?
(Reporter)

Comment 9

6 years ago
> 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
(Reporter)

Comment 10

6 years ago
Ok, now i found it, the issue still remains even with flash HW acceleration and FF hardware acceleration both being disabled.
(Reporter)

Comment 11

6 years ago
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
(Reporter)

Comment 12

6 years ago
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?
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.
(Reporter)

Comment 14

6 years ago
>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.
(Reporter)

Updated

6 years ago
Version: unspecified → Trunk
(Assignee)

Comment 15

6 years ago
(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.
(Reporter)

Comment 16

6 years ago
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

6 years ago
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

5 years ago
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.
Taras, have you got someone who can help investigate this? Flash in a background tab really shouldn't affect foreground perf.

Updated

5 years ago
Whiteboard: [Snappy]
(Assignee)

Comment 20

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

Comment 21

5 years ago
(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
Depends on: 717761

Comment 22

5 years ago
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

5 years ago
(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

5 years ago
(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

5 years ago
(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.
Whiteboard: [Snappy] → [Snappy:P3]

Comment 26

5 years ago
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
(Assignee)

Comment 27

5 years ago
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.
Yes, we could do that, and should do that!
Assignee: nobody → roc
(Assignee)

Comment 29

5 years ago
Got a patch already, so stealing this.
Assignee: roc → tnikkel

Updated

5 years ago
Whiteboard: [Snappy:P3] → [Snappy:P3][sps]
(Assignee)

Comment 30

5 years ago
Created attachment 672643 [details] [diff] [review]
patch

I haven't looked over the new way of doing plugin geometry, but this seems right.
Attachment #672643 - Flags: review?(roc)
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.
Attachment #672643 - Flags: review?(roc) → review+
(Assignee)

Comment 32

5 years ago
https://tbpl.mozilla.org/?tree=Try&rev=477cfa96d394
(Assignee)

Comment 33

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/87df09bc5e8e
https://hg.mozilla.org/mozilla-central/rev/87df09bc5e8e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19

Comment 35

5 years ago
A quick check on my system confirmed that the problem is gone. Thanks for fixing it this promptly.
(Assignee)

Comment 36

5 years ago
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
Attachment #672643 - Flags: approval-mozilla-aurora?
Comment on attachment 672643 [details] [diff] [review]
patch

Approving on aurora . low risk patch for a perf win :)
Attachment #672643 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/626e845bf260
status-firefox18: --- → fixed
status-firefox19: --- → fixed

Updated

5 years ago
Blocks: 579260

Comment 39

5 years ago
(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.
>  
>
Verified fixed FF 18b2, Aurora 19.0a2 (2012-12-05) Win 7.
Status: RESOLVED → VERIFIED
status-firefox18: fixed → verified
status-firefox19: fixed → verified
You need to log in before you can comment on or make changes to this bug.