Closed Bug 642257 Opened 9 years ago Closed 7 years ago

Flash video in background tab degrades FF rendering performance

Categories

(Core :: Plug-ins, defect)

x86
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox18 --- verified
firefox19 --- verified

People

(Reporter: bugzilla.mozilla.org, Assigned: tnikkel)

References

()

Details

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

Attachments

(1 file)

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).
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.
>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
>I'm guessing that we're doing D3D readback on scrolling-boxes
I just tested with HW acceleration off and the issue remains.
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?
> 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
Ok, now i found it, the issue still remains even with flash HW acceleration and FF hardware acceleration both being disabled.
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
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.
>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.
Version: unspecified → Trunk
(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.
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.
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
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.
Whiteboard: [Snappy]
I've read that Flash running puts Windows into high precision timer mode, a possible explanation.
(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
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.
(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?
(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).
(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]
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
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
Got a patch already, so stealing this.
Assignee: roc → tnikkel
Whiteboard: [Snappy:P3] → [Snappy:P3][sps]
Attached patch patchSplinter Review
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+
https://hg.mozilla.org/mozilla-central/rev/87df09bc5e8e
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
A quick check on my system confirmed that the problem is gone. Thanks for fixing it this promptly.
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+
Blocks: 579260
(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
You need to log in before you can comment on or make changes to this bug.