612113 - Performance issues with Flash at MSNBC's Countdown page

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Leman Bennett [Omega]]

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

Comment 1

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

Probably the same as bug 611698.

Comment 2

[Benjamin Smedberg]

Yeah, the transparency issue is bug 611698. Can I get more details about the performance issue you mention?

Comment 3

[juan becerra [:juanb]]

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.

Comment 4

[Leman Bennett [Omega]]

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.

Comment 5

[Benjamin Smedberg]

Jim, can you get some profiles of what's going on here?

Comment 6

[Alex]

CPU idles on 80% on Athlon II P340

Comment 7

[Jim Mathies [:jimm]]

Attachment: simple test case

Comment 8

[Jim Mathies [:jimm]]

Attachment: simple test case

made the video panel larger.

Comment 9

[Jim Mathies [:jimm]]

Attachment: child gui thread profile

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.

Comment 10

[Jim Mathies [:jimm]]

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.

Comment 11

[Jim Mathies [:jimm]]

(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.

Comment 12

[Jim Mathies [:jimm]]

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.

Comment 13

[Jim Mathies [:jimm]]

Attachment: child gui thread profile v.2

Comment 14

[Benjamin Smedberg]

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.

Comment 15

[juan becerra [:juanb]]

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.

Comment 16

[Benjamin Smedberg]

I'll take this to profile firefox.exe.

Comment 17

[Benjamin Smedberg]

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.

Comment 18

[Benjamin Smedberg]

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?

Comment 19

[Benjamin Smedberg]

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.

Comment 20

[juan becerra [:juanb]]

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.

Comment 21

[Leman Bennett [Omega]]

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

Comment 22

[Benjamin Smedberg]

Could people experiencing this please try http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-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.

Comment 23

[Leman Bennett [Omega]]

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.

Comment 24

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

(In reply to comment #22)
> Could people experiencing this please try
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-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.

Comment 25

[Benjamin Smedberg]

No, that's a build with bug 625425.

Comment 26

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Bug 626602 probably wouldn't speed up rendering of transparent plugins, but bug 629866 might have helped.

Comment 27

[Benjamin Smedberg]

I fully suspect that this is a dup of bug 629866. Can somebody try a recent nightly now that that has landed?

Comment 28

[Leman Bennett [Omega]]

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%

Comment 29

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

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.

Comment 30

[Benjamin Smedberg]

I believe that all the major issues here have been resolved, and so I'm going to close this bug out.