Closed Bug 551972 Opened 15 years ago Closed 13 years ago

[d2d] Huge increase in CPU load with windowless plugin pages when d2d is enabled

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking2.0 -)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: u88484, Unassigned)

References

(
URL
)

Details

(Keywords: perf, regression)

I see a huge increase in CPU load when watching plugin videos that are windowsless (videos on cnn.com and hulu.com) compared to windowed plugin videos (youtube.com). The high CPU load is only on the main firefox.exe process though and not on the mozilla-runtime.exe process. Watching a video on CNN causes around 40% CPU load (on the firefox.exe process) with d2d enabled and around 3% with d2d disabled. No noticeable change on the m-r.exe process. http://www.cnn.com/video/#/video/us/2010/03/11/dnt.woman.shoots.flasher.ksat?hpt=C2 http://www.youtube.com/watch?v=d1X4r2nHSb0&feature=rec-rn-2r-3-HM
Blocks: 527707
No longer depends on: 527707
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a29d44f196a6&tochange=475768f37b1a So the main d2d patch caused this regression.
Alpha recovery :( We need to implement the IsOpaque stuff to fix this properly. Or try to think of another way to fix this.
Putting a flash video in a div and messing with the transparency has no effect on performance but once I removed wmode="transparent" the CPU usage skyrockets. note: wmode="transparent" is required for messing with the opacity to have any effect. Jimm said Roc might be able to help out here so CC'ing him.
Here is the code I used to test: <html> <head></head> <body> <div style="opacity:1.0;"> <embed src="http://www.youtube.com/v/eLT-_1liwvU&rel=0&fs=1" type="application/x-shockwave-flash" wmode="transparent" height="500" width="500"> </embed> </div> </body></html> Results d2d enabled: opacity 1.0 = 74% (fx 27, m-r 37), opacity 0.1 = 70% (fx 25, m-r 35) d2d disabled: opacity 1.0 = 50% (fx 9, m-r 32), opacity 0.1 = 70% (fx 29, m-r 32)
The first thing we should do is hook up IsOpaque to set the flag in gfxWindowsNativeDrawing so that alpha recovery is not required. That should mostly fix this.
blocking2.0: --- → ?
How do plugin layers (bug 556487) affect this bug? It looks like we are doing alpha extraction on plugins which might be transparent right now, which involves painting twice and seems a bit unfortunate. Could we do what chromium does and retain the plugin background instead?
blocking2.0: ? → betaN+
(In reply to comment #6) > How do plugin layers (bug 556487) affect this bug? It looks like we are doing > alpha extraction on plugins which might be transparent right now, which > involves painting twice and seems a bit unfortunate. Could we do what chromium > does and retain the plugin background instead? For opaque plugins it shouldn't matter which I think is a lot of them. I'm not sure how hard it would be to execute your suggestion for transparent plugins, I think it'll be very hard to do right with accelerated layers(we'd need to readback), not so much so for non-accelerated layers probably. We should be able to make alpha extraction a couple of times faster by giving it some very simple SSE2 love though, which the vast majority of our users should have by now.
Another thing we should check is, if we give Flash a DIB buffer that's been cleared to RGBA(0,0,0,0), will it fill in the right alpha values? If so, we can special-case Flash to avoid alpha recovery.
I've created a patch giving gfxAlphaRecovery an SSE2 codepath. It seems to perform roughly 8 times faster than the current codepath in my tests, I hope it will behave like that in the wild :-). Hopefully that will atleast improve this situation.
Depends on: 587936
Could people see if this improved with the push of bug 587936?
I'm out unless you can fix D2D/D3D9 first, Kurt?
(In reply to comment #11) > I'm out unless you can fix D2D/D3D9 first, Kurt? You mean D2D on DX9 hardware or...?
(In reply to comment #12) > (In reply to comment #11) > > I'm out unless you can fix D2D/D3D9 first, Kurt? > > You mean D2D on DX9 hardware or...? yeah, I got bitten by the changes on 8-10, and it no longer appears to be working since. Did you want me to file a another bug on that?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > I'm out unless you can fix D2D/D3D9 first, Kurt? > > > > You mean D2D on DX9 hardware or...? > > yeah, I got bitten by the changes on 8-10, and it no longer appears to be > working since. Did you want me to file a another bug on that? There's a bug, and a fix on that bug, it's in the ride-along landing queue. It should be working again in tomorrow's nightly! Sorry!
D2D is working again in the 8-19 for me, Thanks Bas! I on this bug, I'm seeing slight less CPU usage, but still not a big increase. I have a Core 2 Duo with a Nvidia 7050 which is integrated. CPU fluctuates about 50-70 percent most of the time, but if I switch to another tab like this bug, the CPU goes down to about 8-10 percent while the video plays in the background tab. So between this bug and a few others mentioning high CPU, it seems the active tab is the worst offender of CPU usage.
Do DirectX 9.0 cards like nVidia 7050 support D2D now? News to me. I never looked at exact CPU stats, but based on my personal Mafia Wars usage in Facebook, which uses a lot of flash and transparency transitions, feels a lot smoother. Much closer (but not quite the same as) to the Google Chrome experience in the game. I have an Athlon II X4 so I'm not sure how good AMD's SSE2 implementation is. It may be faster on Intel procs.
(In reply to comment #16) > Do DirectX 9.0 cards like nVidia 7050 support D2D now? News to me. > > I never looked at exact CPU stats, but based on my personal Mafia Wars usage in > Facebook, which uses a lot of flash and transparency transitions, feels a lot > smoother. Much closer (but not quite the same as) to the Google Chrome > experience in the game. I have an Athlon II X4 so I'm not sure how good AMD's > SSE2 implementation is. It may be faster on Intel procs. That's good to hear! D2D is not default on on D3D9 hardware, but it does work. The reason it's not on by default is because at this point we're not able to achieve the performance we want, and to justify some of the downsides, on D3D9 hardware.
While bug 587936 certainly helped here, it didn't quite fix the issue. Bas, is it possible that windowless plugins are somehow forcing the browser to re-paint the whole content area? I'm asking this because I noticed three things: 1- Post bug 587936, CPU usage in plugin-container.exe is exactly the same with windowed or windowless plugins, however CPU usage in the firefox.exe process is still a lot higher in windowless cases (2-4% vs 13-20%). Since Firefox is apparently not doing any I/O or painting, this shouldn't happen. 2-Having D2D enabled hurts FPS rate in Quakelive (which is windowless), a lot. This shouldn't happen, since there's nothing to paint while the Quakelive plugin is running, specially when it is in fullscreen mode. 3-With builds from bug 130078 (which as I understand links chrome and content rendering) the FPS issue described above is even worse. If my guess is correct, this is due to the windowless plugin now forcing even the chrome to re-paint itself, even tho it shouldn't.
(In reply to comment #18) > While bug 587936 certainly helped here, it didn't quite fix the issue. Bas, is > it possible that windowless plugins are somehow forcing the browser to re-paint > the whole content area? Very unlikely. In some cases it's possible, but at least D2D would not affect this for windowless plugins. It is not involved in what area is invalidated. > I'm asking this because I noticed three things: > 1- Post bug 587936, CPU usage in plugin-container.exe is exactly the same with > windowed or windowless plugins, however CPU usage in the firefox.exe process is > still a lot higher in windowless cases (2-4% vs 13-20%). Since Firefox is > apparently not doing any I/O or painting, this shouldn't happen. Firefox is doing the work described in bug 587936. Bug 587936 did nothing to affect what plugin-container.exe is doing. Essentially, the plugin-container paints twice with D2D (it still does), and firefox does a bunch of work on those paints to create a single RGBA surface. That process is the CPU usage you're seeing. > 2-Having D2D enabled hurts FPS rate in Quakelive (which is windowless), a lot. > This shouldn't happen, since there's nothing to paint while the Quakelive > plugin is running, specially when it is in fullscreen mode. We'd need to look at what the plugin is doing there internally. > 3-With builds from bug 130078 (which as I understand links chrome and content > rendering) the FPS issue described above is even worse. If my guess is correct, > this is due to the windowless plugin now forcing even the chrome to re-paint > itself, even tho it shouldn't. I'm not sure how the drawing of windowless plugins is affected by 130078 so I don't have any very good explanation for you there.
We don't always need to paint twice for windowless. For windowless plugins that are marked "opaque", we should only need to paint once. nsObjectFrame::IsOpaque will tell you. Just need to add a flag to gfxWindowsNativeDrawing, "IS_OPAQUE", pass it from nsObjectFrame when appropriate. In gfxWindowsNativeDrawing, when that flag is set, we just need to create one temporary surface, draw into it, and we're done.
I have a prototype up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmuizelaar@mozilla.com-78c6a149b77f/tryserver-win32/ that may fix the performance problems people are seeing. Note: it may make drawing of the native theme slower and leak memory. It be great to know if this helps with performance problems people are seeing.
The URL page I now get about 20-40% cpu usage compared to the 50-70% here, but it didn't help much on bugs like bug 579597 where its still about 70%+ there.
blocking2.0: betaN+ → -
Any change / progress on this?
(In reply to Tomas from comment #23) > Any change / progress on this? Kurt, Tomas, are you still seeing this in v7 (beta) or v8 (Aurora)? http://www.mozilla.org/en-US/firefox/channel/
Keywords: perf
Seems perfectly fine on 9.0a1 although I'm on a new computer now but the CPU on the firefox process barely hits 10% and plugin-container around 15% basically the same with and without, just a little higher with d2d enabled. I'd say this is now WFM. Reopen if someone else see's different results.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.