Performance issues with Flash at MSNBC's Countdown page

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: lh.bennett, Assigned: benjamin)

Tracking

({perf, regression})

unspecified
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [softblocker], )

Attachments

(3 attachments, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101113 Firefox/4.0b8pre
Build Identifier: 

Got this report from: http://forums.mozillazine.org/viewtopic.php?f=23&t=2033159&start=0

Apparently there are performance and transparency issues with this particular page and Flash.

Turning off Accelerated Compositing does nothing.

Testing in 3.6.12 produces correct results, no anomalies, painting issues or extreme performance issues.

This could be fallout Bug 611498 or Async Plugin Painting.

Reproducible: Always
blocking2.0: --- → ?
Yeah, the transparency issue is bug 611698. Can I get more details about the performance issue you mention?
On 3.6.13pre, the video plays very smoothly and the combined cpu usage is around 80%, the plugin-container usually using more cpu. On 4.0b8pre, there's a slight but noticeable choppiness, and the combined percentage goes consistently around 90%, with the firefox.exe process using more cpu (almost the reverse).

I tried this on an XP vm, and the CPU usage is definitely higher on 4.0b8pre. On a Win7 hardware machine the cpu usage was similar, but I couldn't tell the difference in video playback.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It consumes a large amount of CPU cycles just by sitting there.

Chrome will drop to 2-8 percent on both container and process after load.

Minefield will drop to 55% on process and 33% on container after load.
Jim, can you get some profiles of what's going on here?
Assignee: nobody → jmathies
blocking2.0: ? → betaN+
Keywords: perf, regression
CPU idles on 80% on Athlon II P340
Posted file simple test case (obsolete) —
Posted file simple test case
made the video panel larger.
Attachment #498184 - Attachment is obsolete: true
Profiling results - these results were recorded with the video paused after the load progress completed.

This is another flash app that paints despite the lack of visual animation. The size of painted area is actually pretty small, about 60 x 150.

ShowPluginFrame and it's children are where we spend a majority of our time independent of message wait loops. PaintRectToSurface and PaintRectToPlatformSurface are the most time consuming children of ShowPluginFrame. (Looks like PaintRectToPlatformSurface is primarily flash painting.)

Note we perform far better on something like this with ipc disabled. I've confirmed we do the same repetitive painting, we just handle the situation better in the non-ipc case.
Does anyone have any trouble getting this video to play?

http://video.citytv.com/video/detail/704674349001.000000/Marionette/

I've tried both ipc enabled/disabled with no success.
(In reply to comment #10)
> Does anyone have any trouble getting this video to play?
> 
> http://video.citytv.com/video/detail/704674349001.000000/Marionette/
> 
> I've tried both ipc enabled/disabled with no success.

whoops, never mind, wrong bug.
Some updates, bsmedberg asked about the possibility of paint races in our async painting. I did some timing tests and found that flash limits paints, 30 fps when video is paused or it playing ads (on the test case here) and 60 fps for video playback. So that doesn't appear to be a problem.

Stepping through the code I don't see why we make use of the mBackSurface code on windows. AFAICT it's useless overhead. I've posted a patch to try for testing purposes that disables this and also has the fps log output. It should be completed in a few hours.
Summary: Transparency & Performance issues with Flash at MSNBC's Countdown page → Performance issues with Flash at MSNBC's Countdown page
Whiteboard: [softblocker]
Juan, can you still reproduce that Firefox is using more CPU than it did, or the choppiness? I'm not so worried about CPU usage in general, but it's suprising that Firefox is using more (and not just the plugin process), and choppiness would likely result if the Firefox event loop is getting backed up.
Assignee: jmathies → nobody
I can still reproduce this using the latest nightlies on XP and Flash 10.1.102.64. The CPU on Minefield goes to about 80% vs 20% for the plugin-container (and slight choppiness), whereas the CPU on Namoroka goes to about 40% vs 35% for the plugin-container (with no choppiness). These are rough numbers, but generally on Minefield the CPU usage is much higher.
I'll take this to profile firefox.exe.
Assignee: nobody → benjamin
A profile of firefox.exe with D3D10 on shows that we're spending most of our time in nvwgf2um.dll, which is the nVidia driver. I'll try with acceleration off next.
Without D3D, I'm still not using a whole lot of CPU, but it's almost evenly divided between these callstacks:

RecvShow -> SharedDIBSurface::Attach -> SharedDIBWin::SetupSurface -> CreateDIBSection

_cairo_d2d_fill -> _cairo_d2d_create_brush_for_pattern D2DRenderTargetBase<ID2D1RenderTarget>::CreateBitmap -> CHwSurfaceRenderTarget::CreateCopiedBitmapFromMemory

The first stack would probably be fixed by bug 625425. I'm not sure about the second stack: Bas, is there something in D2D-land where we should be reusing a bitmap instead of creating a new one for each plugin frame?

Juan/Omega X, when you reproduce this what are your graphics listing from about:support?
With D2D off, we spend over 40% over the firefox.exe CPU time calling BitBlt, but I don't have stacks for it from a nightly build: perhaps a local build without FPO will produce better profiling stacks.
These are the graphics listings from about:support from one of the machines where I see this.

NVIDIA Quadro FX 3450/4000 SDI
10de
00cd
Uknown
nv4_disp
8.4.2.6
n/a
false
false
nvidia -- quadro fx 3450/400/sdi/pci/sse2 -- 2.0.1
1/1 Direct3d 9

I can see it on a VM on my Mac machine as well.
On this XP machine: using Flash 10.1.102.64

With HW Acceleration disabled, Firefox.exe hovers around 7-14% idle.
Plugin_Container.exe hovers around 5-7%.

With Compositing enabled:
Firefox.exe hovers at 75-85% idle.
plugin_container hovers around 6% constant.

Graphics Info:
ATI Radeon HD 4850
1002
9442
Unknown
ati2dvag
8.780.0.0
9-10-2010
false
false (0.0.0.0)
TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 18 2011 03:43:38)
1/1 Direct3D 9
Could people experiencing this please try http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bsmedberg@mozilla.com-d0dceef375bd/try-w32/firefox-4.0b10pre.en-US.win32.installer.exe

I haven't found anything interesting in the profiles I've done with D3D9, either.
Using the build above. 

firefox.exe has 52% load and hovers around 30% idle
plugin_container has 50% load and hovers around 6% idle.

Interaction with the page causes plugin_container to spike to 60%.

Oddly enough switching from the MSNBC tab to another tab without flash causes a constant 3% in plugin_container even though firefox reports zero cpu.
(In reply to comment #22)
> Could people experiencing this please try
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bsmedberg@mozilla.com-d0dceef375bd/try-w32/firefox-4.0b10pre.en-US.win32.installer.exe

That's a build with bug 626602 in it?

I verified that our ReadbackLayer is able to find a ThebesLayer background, so 626602 should definitely be helping.
Depends on: 626602
No, that's a build with bug 625425.
Bug 626602 probably wouldn't speed up rendering of transparent plugins, but bug 629866 might have helped.
I fully suspect that this is a dup of bug 629866. Can somebody try a recent nightly now that that has landed?
With the latest Nightly + Flash 10.2 r152:

firefox.exe load at 76% and idles at 17-19%
plugin-container loads at 36% and idles at 6-8%
That sounds better than the numbers reported before, but I can't tell if that means this bug is fixed or not.

Bug 634844 might help some more here for the accelerated cases.
Depends on: 634844
I believe that all the major issues here have been resolved, and so I'm going to close this bug out.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.