Closed Bug 1172841 Opened 9 years ago Closed 9 years ago

Scrolling performance decreased after enabling Silk when hardware video acceleration is disabled

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
40 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla42
Tracking Flags:
Tracking Status
firefox38.0.5 --- unaffected
firefox39 --- unaffected
firefox40 + wontfix
firefox41 + wontfix
firefox42 + verified

People

(Reporter: Virtual, Assigned: mchang)

References

(
URL
)

Details

(Keywords: nightly-community, perf, regression, Whiteboard: gfx-noted)

Attachments

(42 files, 4 obsolete files)

nobug.png
542.96 KB, image/png
Details
bug.png
1007.48 KB, image/png
Details
about;support.txt
1.35 KB, text/plain
Details
about;plugins.txt
1.85 KB, text/plain
Details
1-bug occur.png
1.00 MB, image/png
Details
2-stabilizing after minimizing and maximizing.png
564.14 KB, image/png
Details
3-looks good, but still missing nearly 1Hz.png
351.64 KB, image/png
Details
2. compositor & hw-vsync.enabled & refreshdriver = false.png
783.07 KB, image/png
Details
2. compositor & hw-vsync.enabled & refreshdriver = true.png
977.46 KB, image/png
Details
2. gfx.vsync.compositor = false.png
1015.84 KB, image/png
Details
2. gfx.vsync.refreshdriver = false.png
751.75 KB, image/png
Details
1. compositor & hw-vsync.enabled & refreshdriver = false.png
1018.78 KB, image/png
Details
1. gfx.vsync.compositor = false.png
1.00 MB, image/png
Details
1. gfx.vsync.refreshdriver = false.png
1.03 MB, image/png
Details
compositor & hw-vsync.enabled & refreshdriver = false
1.97 MB, text/plain
Details
compositor & hw-vsync.enabled & refreshdriver = true
1.89 MB, text/plain
Details
gfx.vsync.compositor = false
852.03 KB, text/plain
Details
gfx.vsync.refreshdriver = false
2.08 MB, text/plain
Details
Chrome 43.0.2357.124-only VSyncTester.png
983.26 KB, image/png
Details
Chrome 43.0.2357.124-VSyncTester+movie playing in background.png
379.75 KB, image/png
Details
Firefox 40.0a2 (2015-06-16)-only VSyncTester.png
981.43 KB, image/png
Details
Firefox 40.0a2 (2015-06-16)-VSyncTester+movie playing in background.png
378.01 KB, image/png
Details
Firefox 41.0a1 (2015-06-16)-only VSyncTester.png
425.30 KB, image/png
Details
Firefox 41.0a1 (2015-06-16)-VSyncTester+movie playing in background on Vimeo.png
993.52 KB, image/png
Details
'patched' Firefox 41.0a1 (2015-06-16)-only VSyncTester.png
938.56 KB, image/png
Details
'patched' Firefox 41.0a1 (2015-06-16)-VSyncTester+movie playing in background.png
1.05 MB, image/png
Details
'patched2' Firefox 41.0a1 (2015-06-17)-only VSyncTester.png
964.09 KB, image/png
Details
'patched2' Firefox 41.0a1 (2015-06-17)-VSyncTester+movie playing in background.png
991.27 KB, image/png
Details
'patched3' Firefox 41.0a1 (2015-06-18)-only VSyncTester.png
947.82 KB, image/png
Details
'patched3' Firefox 41.0a1 (2015-06-18)-VSyncTester+movie playing in background.png
1015.72 KB, image/png
Details
'soft 60Hz' Firefox 41.0a1 (2015-06-29)-only VSyncTester.png
869.11 KB, image/png
Details
'soft 60Hz' Firefox 41.0a1 (2015-06-29)-VSyncTester+movie playing in background.png
334.18 KB, image/png
Details
'soft 65Hz' Firefox 41.0a1 (2015-06-29)-only VSyncTester.png
1022.65 KB, image/png
Details
'soft 65Hz' Firefox 41.0a1 (2015-06-29)-VSyncTester+movie playing in background.png
1.04 MB, image/png
Details
Profile with STR from Comment 76 in Bug #1172841
1.98 MB, text/plain
Details
Chrome h264
48.33 KB, image/png
Details
Firefox - h264 - concurrent scheduling
47.27 KB, image/png
Details
Firefox - vp 9 - 4 threads - staggered scheduling
40.70 KB, image/png
Details
IE w/o Flash - 720p
43.30 KB, image/png
Details
Choose number of video decoder threads based on number of cpus
5.10 KB, patch
cpearce
: review+
Details | Diff | Splinter Review
'final patch' Firefox 42.0a1 (2015-07-20) VSyncTester+movie playing in background [without hardware video acceleration].png
1010.92 KB, image/png
Details
'final patch' Firefox 42.0a1 (2015-07-20) VSyncTester+movie playing in background.png
756.85 KB, image/png
Details 
STR:
1. Use only one window for browsing.
2. Open and play some HD movie in HTML5 mode on YouTube in one tab
3. Open other HD movie in HTML5 mode on YouTube in next tab, after the first one ended
4. Start browsing other sites with new tabs
to get terrible scroll performance

Going to https://www.vsynctester.com/ to see how much FPS I have, shows me on terrible scroll performance nothing, no graph,
but sometimes, when performance is better I can see that FPS isn't the refresh rate of my old LCD (75MHz), but other value like 60 or even 64 and 65MHz.

I suspect it's more reproducible on refresh rated other than 60MHz, which on my new LCD I can't reproduce it that often.
Playing movie isn't the only step to reproduce it as in some cases it can happen without it, after too much idling time.

A tip can be that this terrible and poor scroll performance can be fixed by minimizing Firefox to Start and maximizing it.

Now, I'm testing with only disabled "gfx.vsync.refreshdriver" to see if it's the cause of this issue,
as disabling all three options:
- gfx.vsync.compositor
- gfx.vsync.hw-vsync.enabled
- gfx.vsync.refreshdriver
fixes the issue for me.
Assignee: nobody → mchang
Status: NEW → ASSIGNED
Whiteboard: gfx-noted
Sounds somewhat similar as bug 1172561, which is on Gecko 39 though where silk isn't enabled yet.
See Also: → 1172561
I just tried this but was unable to reproduce. Can you attach your about:support?

Is this always reproducible or just sometimes? IS this on a laptop or desktop? If on a laptop, are you on battery power and is it reproducible when plugged into power? Thanks!
Flags: needinfo?(BernesB)
Attached file about;support.txt — 
It's reproducible, but not always. In less then 25% of trying I would say and like I said it's easier to reproduce if your LCD has refresh rate other than 60MHz.



my whole Desktop PC specs:
CPU: Intel Core 2 Duo E6550 2,33@3,4GHz (default voltage, energy savings options like CPU Enhanced Halt State [C1E] & CPU EIST Function [Enhanced Intel SpeedStep Technology] are disabled)
MOBO: Gigabyte GA-P35C-DS3R (latest BIOS version [F13d], FSB 333@486MHz, FSB:DRAM ratio 1:1, default voltages/timings/speeds, especially PCI-E blocked and locked at 100MHz)
RAM: Kingston HyperX (KHX8500D2K2) 4GB (2x 2GB) DDR2 1066MHz (1066@971MHz, DRAM:FSB ratio 1:1, default memory voltage=2,2V set manually)
GPU: Palit (NE5X4600HD09F) NVIDIA GeForce GTX 460 v2 1GB GDDR5 (GF114; 10DE-1205/0000-0000[Rev A1]) (778MHz/4008MHz, 192bit, BIOS version=70.24.25.00.00; PCIe 2.0x16@1.1x16 due to P35) with 347.88 drivers (newest are bugged on my GPU and giving me constant TDR in every game)
SOUND: Creative Sound Blaster Live! 5.1 with kX drivers (ASIO) 5.10.0.3551
PSU: Corsair VX550W
LCD: LG Flatron W2252TQ (60@76MHz [CVT-R], 1680x1050, 32bit, 96 DPI, connected to GPU with HDMI) [in repair - for backup using now Belinea 10 19 05 (75MHz [CVT], 1280x1024, 32bit)
HDD: Samsung HD103SJ (1TB) [system], Seagate ST3000DM001 (3TB), Samsung HD642JJ (640GB)
SYS: Microsoft Windows 7 Professional (64bit) [with SP1 + all patches, Aero is enabled]

more drivers info:
Chipset Software Installation Utility - 10.0.27 - drivers for motherboard
Rapid Storage Technology - 13.6.0.1002 - drivers for motherboard
LAN drivers - 7.092 - for integrated Realtek 8111B on motherboard
GPU are running in maximum performance mode for all applications (changed manually)
Flags: needinfo?(BernesB)
Can you please add about:plugins as well?
Flags: needinfo?(BernesB)
Attached file about;plugins.txt — 
I have only latest Flash beta enabled in ask to activate mode.
OpenH264 and DRM (Adobe Primetime CDM) are disabled.
Flags: needinfo?(BernesB)
Attached image 1-bug occur.png — 
Some new screenshots how it looks on my end when the bug occurring on https://www.vsynctester.com/
Unfortunately it was still taken with all 3 options as enabled
Hmm that's odd. Can you try these two configurations:

1) Disable only the vsync refresh driver, "gfx.vsync.refreshdriver", restart firefox and try to reproduce.
2) Disable only the vsync compositor, re-enable the vsync refresh driver, "gfx.vsync.compositor;true", restart firefox and try again.


Thanks!
Flags: needinfo?(BernesB)
"1" screenshot attachments are taken with this STR (faster to reproduce the decreasing performance with VSync Silk project):
-open https://www.vsynctester.com/ in first tab and see if VSync synchronization and input lag are OK
-open https://www.youtube.com/watch?v=NRUBe2RTq74 in second tab
-set movie Quality as 1080p (HD) in Settings
-start playing from beginning
-go to first tab with VSyncTester to observe test results
~25 Hz - maybe it normalize refresh rate to frame rate of movie
Removing tracking for firefox39 as silk isn't enabled on windows on gecko 39.
status-firefox39: affected → unaffected
tracking-firefox39: ? → ---
Can you please get a profile while this is happening? You can get a profile here - 

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Thanks!
Flags: needinfo?(BernesB)
(In reply to Virtual_ManPL [:Virtual] from comment #17)
> "1" screenshot attachments are taken with this STR (faster to reproduce the
> decreasing performance with VSync Silk project):
> -open https://www.vsynctester.com/ in first tab and see if VSync
> synchronization and input lag are OK
> -open https://www.youtube.com/watch?v=NRUBe2RTq74 in second tab
> -set movie Quality as 1080p (HD) in Settings
> -start playing from beginning
> -go to first tab with VSyncTester to observe test results

Thanks for these STR! I'm able to reproduce with these steps.
Flags: needinfo?(BernesB)
(In reply to Virtual_ManPL [:Virtual] from comment #17)
> "1" screenshot attachments are taken with this STR (faster to reproduce the
> decreasing performance with VSync Silk project):
> -open https://www.vsynctester.com/ in first tab and see if VSync
> synchronization and input lag are OK
> -open https://www.youtube.com/watch?v=NRUBe2RTq74 in second tab
> -set movie Quality as 1080p (HD) in Settings
> -start playing from beginning
> -go to first tab with VSyncTester to observe test results

If you wait a couple of seconds, does the FPS go back up for you on the VsyncTester tab? I notice i get a dip in FPS For 1-2 "rounds" of the test, then the FPS shoots back up to 60. This happens on Firefox 39 as well where Silk is disabled.
Flags: needinfo?(BernesB)
I had taken these screenshots in about 1:20 of movie time to get stabilized FPS values like you said, but unfortunately they were only going down.

In which case should I create these profiles? Redo the test with my second STR or enable VSync and when bug occur it real life cases as reported firstly like in first STR?
Flags: needinfo?(mchang)
Version: 39 Branch → 40 Branch
(In reply to Virtual_ManPL [:Virtual] from comment #26)
> I had taken these screenshots in about 1:20 of movie time to get stabilized
> FPS values like you said, but unfortunately they were only going down.
> 

So I left the movie tab going during the whole time, went to the VysncTester tab, and left the vsync tester tab untouched for a couple of seconds. The Vsynctester tab FPS counter went down, then back up after a couple of rounds through the animation with the movie continually playing in the background on the second tab.

> In which case should I create these profiles? Redo the test with my second
> STR or enable VSync and when bug occur it real life cases as reported
> firstly like in first STR?

Let's try the second STR since this seems to at least be consistent. I wouldn't be surprised if the DWM is restricting the composite rate for a while due to the movie.
Flags: needinfo?(mchang)
(In reply to Mason Chang [:mchang] from comment #22)
> Removing tracking for firefox39 as silk isn't enabled on windows on gecko 39.

But didn't it make to Firefox 39 per #1140723?
Only refresh driver wasn't enabled in Firefox 39 and made to Firefox 40 per #1144317.
(In reply to Virtual_ManPL [:Virtual] from comment #28)
> (In reply to Mason Chang [:mchang] from comment #22)
> > Removing tracking for firefox39 as silk isn't enabled on windows on gecko 39.
> 
> But didn't it make to Firefox 39 per #1140723?
> Only refresh driver wasn't enabled in Firefox 39 and made to Firefox 40 per
> #1144317.

It was backed out in bug 1150223.
I have these messages when I end Gecko profiler 1.16.1 work and go to Cleopatra using Shift+Ctrl+2

>Symbolization failed
>>Could not understand response from symbolication server at http://symbolapi.mozilla.org/
>>Please consider filing a bug at https://bugzilla.mozilla.org/"

and this Error in Error Console
>"Timestamp: 2015-06-15 19:38:56
>Error: DEPRECATION WARNING: The arguments you're passing to viewSource.xul are using an out-of-date API.
>You may find more details about this deprecation at: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/View_Source_for_XUL_Applications
>chrome://global/content/viewSource.js 316 _loadViewSourceDeprecated
>chrome://global/content/viewSource.js 302 onXULLoaded
>chrome://global/content/viewSource.js 175 handleEvent
>null 0 null
>
>Source File: resource://gre/modules/Deprecated.jsm
>Line: 79

so my question is
Won't it interfere with logs or should I use build in profile and it should be enough?
(In reply to Virtual_ManPL [:Virtual] from comment #30)
> I have these messages when I end Gecko profiler 1.16.1 work and go to
> Cleopatra using Shift+Ctrl+2
> 
> >Symbolization failed
> >>Could not understand response from symbolication server at http://symbolapi.mozilla.org/
> >>Please consider filing a bug at https://bugzilla.mozilla.org/"

This seems like a new bug. Filed as bug 1174818.
Flags: needinfo?(mchang)
What happens if you close the video tab? Does the VsyncTester tab shoot back up to normal FPS?

If you go back to the VsyncTester tab with the movie in the background, does the VsyncTester tab shoot back up to normal FPS after a couple of seconds while leaving the movie in the background?
Also, does this only happen on Nightly or also Developer Edition?
Thanks for these profiles! Can you please answer comments 32 and 33?

From the profiles, nothing looks out of the ordinary... Vsyncs are occurring at regular intervals and we are able to keep up and composite/tick the refresh drivers in regular intervals. I know that when we play the movie, we throttle the tab with the VsyncTester in the background since it's not a foreground tab. This was part of bug 1145439. 

I'm able to get really bad FPS for a couple of seconds, but then once the tab is in the foreground for a couple of seconds, everything goes back to normal.  Thanks for all the debug info!
Flags: needinfo?(BernesB)
(In reply to Mason Chang [:mchang] from comment #32)
> What happens if you close the video tab? Does the VsyncTester tab shoot back
> up to normal FPS?
Yes, but not like before. It will has ~1 Hz less. See Comment #9, Comment 10 & Comment #11.

(In reply to Mason Chang [:mchang] from comment #32)
> If you go back to the VsyncTester tab with the movie in the background, does
> the VsyncTester tab shoot back up to normal FPS after a couple of seconds
> while leaving the movie in the background?
No, it still goes down like I said in STR in Comment #17.

(In reply to Mason Chang [:mchang] from comment #33)
> Also, does this only happen on Nightly or also Developer Edition?
I didn't tried Aurora/Developer Edition, but it's probably the same if it has all 3 VSync values enabled.

(In reply to Mason Chang [:mchang] from comment #38)
> I know that when we play the movie, we
> throttle the tab with the VsyncTester in the background since it's not a
> foreground tab.
VSyncTester is foreground tab in the end per my STR in Comment #17.
Flags: needinfo?(BernesB)
This is really confusing... From comment 9 and 10, it looks like the test cannot read the value of the refresh rate of the display. I was able to cause this manually by creating a new window and moving a new window continuously over the test. VsyncTester once in a while, can lose the refresh rate of the display at which point the whole test starts going haywire and the FPS drops. I wonder if this is something with the DWM then. 

Can you please test the following?
1) Does this happen in IE / Chrome with the STR in comment 17? I just want to verify it isn't the DWM rate lmiting.
2) If you create a new profile, does this still happen?
3) I just looked at your about:support again and notice that you have hardware video decoding disabled. I tried that on my two test machines, and the requestAnimationFrame red line goes crazy like your screenshots. Is there a reason you have hardware video decoding disabled? Can you try enabling it in about:config and see if you get the same results?
4) Can you still try developer edition?
5) Does this only happen with youtube 1080p videos? What about vimeo? Is youtube defaulting to the html5 player or flash player for you?

Thanks!
Flags: needinfo?(BernesB)
Can you also try this build - https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-fc68ed21b4de/ - It changes the swapchain to use the display's refresh rate rather than 60 hz.
(In reply to Mason Chang [:mchang] from comment #40)
> 1) Does this happen in IE / Chrome with the STR in comment 17? I just want
> to verify it isn't the DWM rate lmiting.
No.
I tested Chrome 43.0.2357.124 [Portable] and it didn't happen.
See Comment 42 & Comment 43.

(In reply to Mason Chang [:mchang] from comment #40)
> 2) If you create a new profile, does this still happen?
Yes.
I tested Firefox 40.0a2 (2015-06-16) [Portable] with clean new fresh profile without any addons (extensions and plugins) and it still happens.
See Comment 44 & Comment 45.

(In reply to Mason Chang [:mchang] from comment #40)
> 3) I just looked at your about:support again and notice that you have
> hardware video decoding disabled. I tried that on my two test machines, and
> the requestAnimationFrame red line goes crazy like your screenshots. Is
> there a reason you have hardware video decoding disabled? Can you try
> enabling it in about:config and see if you get the same results?
I didn't disable it manually in about:config.
Even on Firefox 40.0a2 (2015-06-16) [Portable] with clean new fresh profile without any addons (extensions and plugins) in about:support under "Graphics" section "Supports Hardware H264 Decoding" has "false" value.
What value in about:config control this? So I could enable it manually.

The other cause can be that the auto detection in bugged, so I have it disabled even on supported configuration
or it's enabled and the value there is shown wrongly.

(In reply to Mason Chang [:mchang] from comment #40)
> 4) Can you still try developer edition?
Yes.
I tested Firefox 40.0a2 (2015-06-16) [Portable] with clean new fresh profile without any addons (extensions and plugins) and it still happens.
See Comment 44 & Comment 45.

(In reply to Mason Chang [:mchang] from comment #40)
> 5) Does this only happen with youtube 1080p videos?
No.
Other movie sites are also affected.
It can even happen on non movie site, but it's extremely hard to reproduce.

(In reply to Mason Chang [:mchang] from comment #40)
> What about vimeo?
It also occurs also on Vimeo, but it's not that visible like on YouTube.
With my second STR from Comment 17 and https://vimeo.com/12112529 it still happens.
See Comment 46 & Comment 47.

> Is youtube defaulting to the html5 player or flash player for you?
HTML5 player
(In reply to Virtual_ManPL [:Virtual] from comment #48)
> Even on Firefox 40.0a2 (2015-06-16) [Portable] with clean new fresh profile
> without any addons (extensions and plugins) in about:support under
> "Graphics" section "Supports Hardware H264 Decoding" has "false" value.
> What value in about:config control this? So I could enable it manually.

You can set "media.hardware-video-decoding.enabled" to true.
Adding a tracking flag for FF40 and FF41 as slow-down of scrolling has a pretty negative impact on our end-users.
tracking-firefox40: ? → +
tracking-firefox41: ? → +
(In reply to Mason Chang [:mchang] from comment #41)
> Can you also try this build -
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> mchang@mozilla.com-fc68ed21b4de/ - It changes the swapchain to use the
> display's refresh rate rather than 60 hz.
I pasted your build into Firefox 41.0a1 (2015-06-16) [Portable] with clean new fresh profile without any addons (extensions and plugins), tested it and unfortunately it still happens.
See Comment 51 and Comment 52.

(In reply to Mason Chang [:mchang] from comment #49)
> (In reply to Virtual_ManPL [:Virtual] from comment #48)
> > Even on Firefox 40.0a2 (2015-06-16) [Portable] with clean new fresh profile
> > without any addons (extensions and plugins) in about:support under
> > "Graphics" section "Supports Hardware H264 Decoding" has "false" value.
> > What value in about:config control this? So I could enable it manually.
> 
> You can set "media.hardware-video-decoding.enabled" to true.
I have this preference set to "true" by default, as it's not bolded, so I didn't change it.
Looks like it can be what I said in this comment
(In reply to Virtual_ManPL [:Virtual] from comment #48)
> The other cause can be that the auto detection in bugged, so I have it
> disabled even on supported configuration
> or it's enabled and the value there is shown wrongly.
Can you please try this build? It forces 75 hz with software vsync. Thanks!

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-9c0184da5667/
Flags: needinfo?(BernesB)
See Also: → 1163454
(In reply to Mason Chang [:mchang] from comment #54)
> Can you please try this build? It forces 75 hz with software vsync. Thanks!
> 
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> mchang@mozilla.com-9c0184da5667/
I would say it looks worse on VSyncTester.
Compare Comment 55 and Comment 46.
The issue is still present even with this build.
See Comment 56.
From comment 5:

"LG Flatron W2252TQ (60@76MHz [CVT-R], 1680x1050, 32bit, 96 DPI, connected to GPU with HDMI) [in repair - for backup using now Belinea 10 19 05 (75MHz [CVT], 1280x1024, 32bit)"

Which monitor are you using? Are both connected and both running at 75 hz or only the LG is connected with HDMI running at 75 hz?
Flags: needinfo?(BernesB)
ohhh, thanks for notice, I made mistake there

(In reply to Virtual_ManPL [:Virtual] from comment #5)
> LCD: LG Flatron W2252TQ (60@76MHz [CVT-R], 1680x1050, 32bit, 96 DPI,
> connected to GPU with HDMI) [in repair - for backup using now Belinea 10 19
> 05 (75MHz [CVT], 1280x1024, 32bit)

should be
LCD: LG Flatron W2252TQ (60@76MHz [CVT-R], 1680x1050, 32bit, 96 DPI, connected to GPU with DVI-D) [in repair - for backup using now Belinea 10 19 05 (75MHz [CVT], 1280x1024, 32bit, 96 DPI, connected to GPU with D-Sub)
Flags: needinfo?(BernesB)
What do you mean by in repair - for backup? Sorry, I'm still confused, which monitor is connected or are both connected?
Flags: needinfo?(BernesB)
Now I'm using Belinea 10 19 05 (75MHz [CVT], 1280x1024, 32bit, 96 DPI, connected to GPU with D-Sub),
but the issue also occurred on LG Flatron W2252TQ (60@76MHz [CVT-R], 1680x1050, 32bit, 96 DPI, connected to GPU with DVI-D) which is in repair.
Flags: needinfo?(BernesB)
Can you please try this build? It always keeps vsync enabled to see if we're disabling vsync for some reason.

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-f6be4ccd1bb5/
Flags: needinfo?(BernesB)
(In reply to Mason Chang [:mchang] from comment #62)
> Can you please try this build? It always keeps vsync enabled to see if we're
> disabling vsync for some reason.
> 
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> mchang@mozilla.com-f6be4ccd1bb5/
The issue is still present even with this build.
I would say it looks the same as on normal build without patch.
See Comment 63 and Comment 64.
Just out of curiosity:

1) What is your CPU usage during the scrolling being slow?
2) Does this still happen with e10s enabled?

Thanks!
Flags: needinfo?(virtual616)
(In reply to Mason Chang [:mchang] from comment #66)
> 1) What is your CPU usage during the scrolling being slow?
I think it's 100% usage of 1 of the cores,
but I will need to test it with original STR and task manager minimized,
as when I open other program window or minimize and maximize the browser window it will fix itself.

(In reply to Mason Chang [:mchang] from comment #66)
> 2) Does this still happen with e10s enabled?
Yes.
It still happens with e10s enabled,
but I have e10s disabled due to still many bugs and crashes, slower performance and awful spinner on tab switch.
Flags: needinfo?(virtual616)
> (In reply to Mason Chang [:mchang] from comment #49)
> > (In reply to Virtual_ManPL [:Virtual] from comment #48)
> > > Even on Firefox 40.0a2 (2015-06-16) [Portable] with clean new fresh profile
> > > without any addons (extensions and plugins) in about:support under
> > > "Graphics" section "Supports Hardware H264 Decoding" has "false" value.
> > > What value in about:config control this? So I could enable it manually.
> > 
> > You can set "media.hardware-video-decoding.enabled" to true.
> I have this preference set to "true" by default, as it's not bolded, so I
> didn't change it.
> Looks like it can be what I said in this comment
> (In reply to Virtual_ManPL [:Virtual] from comment #48)
> > The other cause can be that the auto detection in bugged, so I have it
> > disabled even on supported configuration
> > or it's enabled and the value there is shown wrongly.

FYI - I reported this in bug #1178098
I was looking to buy the LG W2252TQ since the Belinea 10 19 05 doesn't seem to be an available model on Amazon. From looking at the LG W2252TQ specs (http://www.engadget.com/products/lg/w2252tq/specs/), it looks like it should only support a 60 hz refresh rate. Are you explicitly overclocking the monitor to 76 hz from comment 59?
Flags: needinfo?(bernesb)
Also, I just want to see if we're pushing your CPU to 100%, hence the jankiness. Can you please try these two builds:

1) Software vsync at 60 hz - https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-73596aad690c/

2) Software vsync at 65 hz - https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-a9004d927ed7/

Can you please report your CPU usage with these two builds?
(In reply to Mason Chang [:mchang] from comment #69)
> I was looking to buy the LG W2252TQ since the Belinea 10 19 05 doesn't seem
> to be an available model on Amazon. From looking at the LG W2252TQ specs
> (http://www.engadget.com/products/lg/w2252tq/specs/), it looks like it
> should only support a 60 hz refresh rate. Are you explicitly overclocking
> the monitor to 76 hz from comment 59?
Yes, I overclocked LG Flatron W2252TQ like I said before. It has normal 60Hz in CVT mode, but when I changed mode to CVT-R, I can go even to 76Hz.
But the issue also happens without overclocking on LG Flatron W2252TQ in 60Hz, same like in Belinea 10 19 05 set to 60Hz, as I have 2 options in settings: 60Hz and 75Hz.

(In reply to Mason Chang [:mchang] from comment #70)
> Also, I just want to see if we're pushing your CPU to 100%, hence the jankiness.
Yes, CPU usage is nearly 100% in both builds from Comment 70.

> 1) Software vsync at 60 hz -
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> mchang@mozilla.com-73596aad690c/
I would say it looks worse on VSyncTester.
Compare Comment 71 and Comment 46.
The issue is still present even with this build.
See Comment 72.

> 2) Software vsync at 65 hz -
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> mchang@mozilla.com-a9004d927ed7/
I would say it looks worse on VSyncTester.
Compare Comment 73 and Comment 46.
The issue is still present even with this build.
See Comment 74.

(In reply to Mason Chang [:mchang] from comment #70)
> Can you please report your CPU usage with these two builds?
CPU usage is nearly 100% in both builds from Comment 70.
Thanks! What's your CPU usage with Silk disabled? Are you doing custom builds or just a stock nightly? How are you profiling? From the profiles, it's very different than 100% cpu usage. From the profiles you uploaded, it looks like everything is working great..

If you're using the Gecko Profile addon, can you stop the profiler once the issue is occurring. Then start the profiler again, let it run for 3-4 seconds, and push analyze?
Flags: needinfo?(bernesb)
(In reply to Mason Chang [:mchang] from comment #76)
> What's your CPU usage with Silk disabled?
CPU usage varies from 50 to 75% on both cores.

(In reply to Mason Chang [:mchang] from comment #76)
> Are you doing custom builds or just a stock nightly?
I downloading your build in ZIP file and pasting it on Nightly (Portable) with clean new fresh profile without any addons (extensions and plugins). I just only disabling e10s due to still many bugs and crashes, slower performance and awful spinner on tab switch.

(In reply to Mason Chang [:mchang] from comment #76)
> How are you profiling?
I was profiling with SRT from Comment 17 with Gecko profiler 1.16.1

(In reply to Mason Chang [:mchang] from comment #76)
> From the profiles it's very different than 100% cpu usage.
> From the profiles you uploaded, it
> looks like everything is working great..
So looks like Gecko profiler 1.16.1 is or were bugged or it didn't profile everything completely.

(In reply to Mason Chang [:mchang] from comment #76)
> If you're using the Gecko Profile addon, can you stop the profiler once the
> issue is occurring. Then start the profiler again, let it run for 3-4
> seconds, and push analyze?
After about 5-10min very long analyzing with these STR and my from Comment 17, I finally get analyzed profile with Gecko profiler 1.16.3, look on Comment 77 or
http://people.mozilla.org/~bgirard/cleopatra/#report=02d4e851399906c3928e65642398406b162642cc



It's still very odd that you can't reproduce it on your PC with Windows system,
as I can reproduce it on every PC with it. So it's not dependent related on CPU and GPU.
(In reply to Virtual_ManPL [:Virtual] from comment #78)
> (In reply to Mason Chang [:mchang] from comment #76)
> > If you're using the Gecko Profile addon, can you stop the profiler once the
> > issue is occurring. Then start the profiler again, let it run for 3-4
> > seconds, and push analyze?
> After about 5-10min very long analyzing with these STR and my from Comment
> 17, I finally get analyzed profile with Gecko profiler 1.16.3, look on
> Comment 77 or
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=02d4e851399906c3928e65642398406b162642cc

Thank you! This profile doesn't have symbols, so I can't tell exactly what's going on. Can you do the same STR you did to get this profile but just with a stock nightly? Not a custom build? We're getting 60ms paints for some reason, but at least this profile clearly points to something wrong. 
 
> It's still very odd that you can't reproduce it on your PC with Windows
> system,
> as I can reproduce it on every PC with it. So it's not dependent related on
> CPU and GPU.

I've tried with 2 PCs and can't reproduce at all. Amazon shipped the LG monitor, so I'm hoping to try to reproduce it once it arrives. Thanks again!
Flags: needinfo?(bernesb)
Oh and if you get an error about the symbol API from the Gecko profile, please change this in about config:

profile.symbolicationUrl to: http://symbolapi.mocotoolsstaging.net
(In reply to Mason Chang [:mchang] from comment #79)
> This profile doesn't have symbols, so I can't tell exactly what's
> going on. Can you do the same STR you did to get this profile but just with
> a stock nightly? Not a custom build?
Odd... As I was thinking that I was testing latest Nightly from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

This is second profile - http://people.mozilla.org/~bgirard/cleopatra/#report=71fe18553112d2d4325983087114553a854e8053




(In reply to Mason Chang [:mchang] from comment #80)
> Oh and if you get an error about the symbol API from the Gecko profile,
> please change this in about config:
> 
> profile.symbolicationUrl to: http://symbolapi.mocotoolsstaging.net
Done. I also changed these preferences:
layers.dump = true
layout.display-list.dump = true
profiler.displaylistdump = true
profiler.layersdump = true
so you will get more data, which may be some help.
Flags: needinfo?(bernesb)
(In reply to Virtual_ManPL [:Virtual] from comment #81)
> (In reply to Mason Chang [:mchang] from comment #79)
> > This profile doesn't have symbols, so I can't tell exactly what's
> > going on. Can you do the same STR you did to get this profile but just with
> > a stock nightly? Not a custom build?
> Odd... As I was thinking that I was testing latest Nightly from
> https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-
> central/
> 
> This is second profile -
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=71fe18553112d2d4325983087114553a854e8053

Thanks! This is very helpful. For some reason, the DrawTargetD2D1::Flush() spends lots of time waiting. And the Compositor just looks like it's idle for no good reason, waiting on something as well. Since the Compositor markers are in the profiler, it looks like the vsync signal is making it to the compositor thread as well. Essentially, for some reason, it looks like both the main thread and compositor thread are just waiting around, not sure why. Digging.
Just out of curiosity, do you have the same problem with a d2d and a skia canvas backend? You can go to about:config and set this preference:

gfx.canvas.azure.backends to "direct2d".

Then restart.

Try again with changing gfx.canvas.azure.backends to "skia".

You don't need to take screenshots again. I'm just wondering if it only occurs with a d2d1 backend. Thanks!
Flags: needinfo?(bernesb)
I just received this monitor and can kind of reproduce. Sometimes, things get really bad, but it also gets bad with Silk disabled. If the flush occurs at just the right time, we can still get 30+ ms pauses, it just usually doesn't occur at the same time. Also, with this monitor, it can be bad even at 60 hz, it doesn't necessarily require 75 hz.

I tried with a d2d backend, most of the time, the flush takes only 2-3 ms.
Flags: needinfo?(bernesb)
Another profile - http://people.mozilla.org/~bgirard/cleopatra/#report=86ba3012b9cf771324faa00993a883037c5fe2c4&selection=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,162,17,163,164,165,166,167,168,169,170,171

This time on a Dell 2408WFP with Silk Enabled. We see some long rasterize times, but nowhere near as bad as with the LG Flatron W2252TQ. Interesting that a different monitor can trigger this...
(In reply to Mason Chang [:mchang] from comment #83)
> Just out of curiosity, do you have the same problem with a d2d and a skia
> canvas backend? You can go to about:config and set this preference:
> 
> gfx.canvas.azure.backends to "direct2d".
> 
> Then restart.
> 
> Try again with changing gfx.canvas.azure.backends to "skia".
> 
> You don't need to take screenshots again. I'm just wondering if it only
> occurs with a d2d1 backend. Thanks!
Yes, the bug occurs with all 'gfx.canvas.azure.backends" values, tested:
-direct2d1.1
-direct2d
-skia
-cairo



(In reply to Mason Chang [:mchang] from comment #84)
> I just received this monitor and can kind of reproduce. Sometimes, things
> get really bad, but it also gets bad with Silk disabled.

> it can be bad even at 60 hz, it doesn't necessarily require 75 hz.
So it's like I said in
(In reply to Virtual_ManPL [:Virtual] from comment #75)
> Yes, I overclocked LG Flatron W2252TQ like I said before. It has normal 60Hz
> in CVT mode, but when I changed mode to CVT-R, I can go even to 76Hz.
> But the issue also happens without overclocking on LG Flatron W2252TQ in
> 60Hz, same like in Belinea 10 19 05 set to 60Hz, as I have 2 options in
> settings: 60Hz and 75Hz.
Adding a tracking flag for FF42. This is a regression and has a pretty negative end-user impact.
tracking-firefox42: ? → +
I changed my machine to have two cores and I can mostly replicate the same thing. What seems to be going on is that the DrawTargetD2D1::Flush calls some internal libs, which start rasterizing. The rasterizing threads in direct 2d get pre-empted since they happen at roughly the same time we have to decode the video. The video decoder takes both threads, each which takes 30-40ms to process, which means that incidentally, the main thread has to wait. However, this is happening for me on non-silk builds as well.

Can you get another profile like in comment 81 but with silk disabled? Thanks!
Please see comment 88.
Flags: needinfo?(bernesb)
Can you also try with this build - https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-d0df2e00cc73/

This reduces the number of threads that are available to the video decoder to 1 thread. Just want to test and make sure that we're hitting the same issue. Thanks!
(In reply to Mason Chang [:mchang] from comment #88)
>However, this is happening for me on non-silk builds as well.
Yes, but I get higher FPS and lower CPU usage with VSync disabled.
What's more don't forget that STR from Comment 17 are specific kind of steps to fast reproduce this issue, as most of time it can even happens on non movie sites, but it's extremely hard to reproduce. Let's hope the patch will also fix this.



(In reply to Mason Chang [:mchang] from comment #88)
> Can you get another profile like in comment 81 but with silk disabled?
Sure. I redo the test with STR from Comment 17 on latest Firefox Nightly 42.0a1 (2015-07-09) with clean new fresh profile without any addons (extensions [only Gecko Profiler 1.16.3 is installed] and plugins) from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
-VSync=on - http://people.mozilla.org/~bgirard/cleopatra/#report=dd794e9a29a827d53881c6c5509b53026af9e122
-VSync=off - http://people.mozilla.org/~bgirard/cleopatra/#report=41e74cf3fa9e89b8ad7ecfefd2069a55762ce3ab

changed values of preferences in about:config:
-browser.dom.window.dump.enabled=true
-datareporting.healthreport.logging.dumpEnabled=true
-devtools.dump.emit=true
-layers.dump=true
-layout.display-list.dump=true
-memory.dump_reports_on_oom=true
-memory_info_dumper.watch_fifo.enabled=true
-profiler.displaylistdump=true
-profiler.layersdump=true



(In reply to Mason Chang [:mchang] from comment #90)
> Can you also try with this build -
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> mchang@mozilla.com-d0df2e00cc73/
> 
> This reduces the number of threads that are available to the video decoder
> to 1 thread. Just want to test and make sure that we're hitting the same
> issue. Thanks!
Looks like the issue reproducible with STR from Comment 17 is in 99% fixed.
The only thing I'm still seeing is:
-slower time to recover FPS refresh rate from swapping the tab from movie to VSyncTester compared to Chrome
-some FPS fluctuations happens sometimes, FPS isn't that rock stable as compared to Chrome
Flags: needinfo?(bernesb)
(In reply to Virtual_ManPL [:Virtual] from comment #91)

Thank you so much for all your testing! So from your comments, it looks like we're hitting the same issue. Thank you for your patience as I tried to reproduce this. The essential problem is that with hardware video decoding disabled and 2 cores playing a 1080p video, it takes both threads roughly 30-50ms to decode the video on the CPU. The OS prioritizes these threads over the direct 2d threads, which cause the main thread to essentially block on the video threads. Since we scroll on the main thread, we get janky scrolling. This is actually a series of unfortunate timings that just squeaked by on your machine with vsync disabled. From comment 75, it still happens with 60hz software vsync, just the timing with the main thread and the video decoder lined up to block more :( in that build.

I can kind of reproduce these issues on both Chrome and IE. You have to disable hardware acceleration in Chrome though to achieve the same results. Chrome also, by default on youtube, plays that video as webm, not h264. We have webm support in Firefox, but not enabled by default yet. You can enable webm by setting the preference "media.mediasource.webm.enabled" to true in about:config, but we don't do hardware webm decoding yet, so the results should be roughly the same. Interestingly enough, Chrome with hardware acceleration disabled reports a 60hz refresh rate on vsynctester.com. Also, Chrome seems to do something special to reduce CPU usage of video on background tabs. I can see the CPU usage for the video tab drop dramatically when I switch the tab to vsynctester.com, which gives more CPU usage for vsynctester.com to run.

I can reproduce it in IE by disabling hardware acceleration in Flash as IE defaults to Flash for me. The FPS counter goes from ~75hz to 65 hz. IE also seems to drop CPU usage of background video tabs.

> (In reply to Mason Chang [:mchang] from comment #88)
> >However, this is happening for me on non-silk builds as well.
> Yes, but I get higher FPS and lower CPU usage with VSync disabled.
> What's more don't forget that STR from Comment 17 are specific kind of steps
> to fast reproduce this issue, as most of time it can even happens on non
> movie sites, but it's extremely hard to reproduce. Let's hope the patch will
> also fix this.

So the biggest problem with the configuration you have and with vsync disabled, is that with vsync disabled, we actually do less work. Previously, before Silk, we would paint/composite at a constant 60 hz. Since your monitor has a refresh rate of 75 hz, we do an extra 25% more work, increasing CPU usage. This is probably why it's a lot harder to reproduce at 60 hz or non movie sites. It might be some ad or movie in the background, but if the main thread has to do 25% less work, the blocking problem will happen a lot less. Unfortunately, this seems to happen since your machine has hardware video decoding disabled :(.

> (In reply to Mason Chang [:mchang] from comment #88)
> > Can you get another profile like in comment 81 but with silk disabled?
> Sure. I redo the test with STR from Comment 17 on latest Firefox Nightly
> 42.0a1 (2015-07-09) with clean new fresh profile without any addons
> (extensions [only Gecko Profiler 1.16.3 is installed] and plugins) from
> https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-
> central/
> -VSync=on -
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=dd794e9a29a827d53881c6c5509b53026af9e122
> -VSync=off -
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=41e74cf3fa9e89b8ad7ecfefd2069a55762ce3ab
> 
> changed values of preferences in about:config:
> -browser.dom.window.dump.enabled=true
> -datareporting.healthreport.logging.dumpEnabled=true
> -devtools.dump.emit=true
> -layers.dump=true
> -layout.display-list.dump=true
> -memory.dump_reports_on_oom=true
> -memory_info_dumper.watch_fifo.enabled=true
> -profiler.displaylistdump=true
> -profiler.layersdump=true
> 
> 

Thanks for these profiles! From the profiles, it looks like e10s is enabled on these machines. However, non-vsync profile looks like the system is idle. Can you please try to get this profile again? Stop the profiler, then push start again once the situation happens, let it run for a few seconds, and push analyze.

> 
> (In reply to Mason Chang [:mchang] from comment #90)
> > Can you also try with this build -
> > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> > mchang@mozilla.com-d0df2e00cc73/
> > 
> > This reduces the number of threads that are available to the video decoder
> > to 1 thread. Just want to test and make sure that we're hitting the same
> > issue. Thanks!
> Looks like the issue reproducible with STR from Comment 17 is in 99% fixed.
> The only thing I'm still seeing is:
> -slower time to recover FPS refresh rate from swapping the tab from movie to
> VSyncTester compared to Chrome

From bug 1178098, you're getting hardware accelerated video decoding on Chrome and software rasterization. You can try disabling hardware acceleration in chrome here - http://www.solveyourtech.com/turn-hardware-acceleration-google-chrome/. This should represent, at least for video decoding, what your configuration is ending up in Firefox. But since Chrome does something with background tabs, vsynctester.com still runs fine for me. If I have both windows open, each with half the screen, so that the video is playing as well as vsynctester.com is in the foreground, the frame rate drops.

> -some FPS fluctuations happens sometimes, FPS isn't that rock stable as
> compared to Chrome

Hardware acceleration helps a lot :/.
From chatting with mattwoodrow, it looks like the short term solution is to limit the number of video decoding threads to (# of cores - 1) so that at least one core can still scroll the main thread. The long term solution is to probably not decode video of background tabs.
Choose the number of decoder threads based on number of CPU cores. Choose (#number of cores - 1) so that the main thread isn't always blocked. If we have over 4 cores, let WMF decide how many cores.
Attachment #8631869 - Flags: review?(matt.woodrow)
Blocks: 1182327
(In reply to Mason Chang [:mchang] from comment #92)
> So the biggest problem with the configuration you have and with vsync
> disabled, is that with vsync disabled, we actually do less work. Previously,
> before Silk, we would paint/composite at a constant 60 hz. Since your
> monitor has a refresh rate of 75 hz, we do an extra 25% more work,
> increasing CPU usage. This is probably why it's a lot harder to reproduce at
> 60 hz or non movie sites. It might be some ad or movie in the background,
> but if the main thread has to do 25% less work, the blocking problem will
> happen a lot less.
I just wonder how this issue will look like on 144Hz or 120Hz LCD. Probably an overkill.



(In reply to Mason Chang [:mchang] from comment #92)
> Unfortunately, this seems to happen since your machine
> has hardware video decoding disabled :(.
Odd that we don't have forcing value for hardware accelerated video decoding in about:config like for others hardware accelerations. But I hope for fast fix in Bug #1178098.



(In reply to Mason Chang [:mchang] from comment #92)
> Thanks for these profiles! From the profiles, it looks like e10s is enabled
> on these machines. However, non-vsync profile looks like the system is idle.
> Can you please try to get this profile again? Stop the profiler, then push
> start again once the situation happens, let it run for a few seconds, and
> push analyze.
Yes. I didn't disable e10s that time, but now I do both options.

I retested it on latest Firefox Nightly 42.0a1 (2015-07-09) with clean new fresh profile without any addons (extensions [only Gecko Profiler 1.16.3 is installed] and plugins) from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

STR:
1. Open https://bugzilla.mozilla.org/show_bug.cgi?id=1172841#c17
2. Open from it https://www.vsynctester.com/ in background tab with CTRL button shortcut
3. Do not swap for it now. Wait for end of webpage loading. When it end, swap to VSyncTester tab and wait 5-10s to get 2 green passes on whole graph
4. Go back to Bugzilla tab and open from it https://www.youtube.com/watch?v=NRUBe2RTq74 in background tab with CTRL button shortcut
5. Change player size to "Theater mode"
6. Change "Quality:" to "1080p HD" in "Settings"
7. Start playing from the beginning and wait 5-10s in this tab
8. Swap to VSyncTester tab

Results:
- e10s enabled:
-- Silk enabled - http://people.mozilla.org/~bgirard/cleopatra/#report=2f77d519f985576322b11849a109b0e7e2b352fd
-- Silk disabled - http://people.mozilla.org/~bgirard/cleopatra/#report=6aed31fc394f514e7dcf063543b98a09ca70791c
- e10s disabled:
-- Silk enabled - http://people.mozilla.org/~bgirard/cleopatra/#report=e12967527661a5ae5cba55a56d60f51f5db1956f
-- Silk disabled - http://people.mozilla.org/~bgirard/cleopatra/#report=c5a537d4f0fa87dde561b28d83d9b5b42cf64be7

changed values of preferences in about:config:
- browser.dom.window.dump.enabled=true
- datareporting.healthreport.logging.dumpEnabled=true
- devtools.dump.emit=true
- layers.dump=true
- layout.display-list.dump=true
- memory.dump_reports_on_oom=true
- memory_info_dumper.watch_fifo.enabled=true
- profiler.displaylistdump=true
- profiler.layersdump=true
- profile.symbolicationUrl=http://symbolapi.mocotoolsstaging.net/



(In reply to Mason Chang [:mchang] from comment #92)
> From bug 1178098, you're getting hardware accelerated video decoding on
> Chrome and software rasterization. You can try disabling hardware
> acceleration in chrome here -
> http://www.solveyourtech.com/turn-hardware-acceleration-google-chrome/. This
> should represent, at least for video decoding, what your configuration is
> ending up in Firefox. But since Chrome does something with background tabs,
> vsynctester.com still runs fine for me. If I have both windows open, each
> with half the screen, so that the video is playing as well as
> vsynctester.com is in the foreground, the frame rate drops.
> 
> > -some FPS fluctuations happens sometimes, FPS isn't that rock stable as
> > compared to Chrome
> 
> Hardware acceleration helps a lot :/.
Yes. With disabled "Use hardware acceleration when available" in Settings in Chrome, I can reproduce this issue with nearly same effect like it's now in Firefox. Chrome just simply faster regain stable FPS compared to Firefox.
Attached image Chrome h264 — 
2116, 4976 - Two decoder threads with h264, staggered scheduling.
796, 3532 - Two decoder threads, concurrent scheduling, pre-empting d2d rasterizer threads.
Nightly with vp9, staggered scheduling of 4 decoder threads.
Attached image IE w/o Flash - 720p — 
IE w/o Flash, 720p video
From our discussion this morning in the daily, we had a few things to investigate some more. All tests were done with 2 physical cores on the Core i-7 with Hyperthreading and Turboboost disabled. Previous measurements in this bug were done with 1 physical core with hyperthreading. All tests were done with hardware video acceleration disabled if possible.

1) Does this issue still occur with 2 physical cores and without hyperthreading and turboboost?

Yes - The issue still happens with a noticeable drop in FPS. The FPS drop is just a tad worse than with 1 core and hyperthreading, but it might just be measurement noise.

What's mostly interesting though, is that the blocking on the decoder thread still happens. But the time spent in the decoder thread has dropped to ~20 ms instead of ~30-40ms. The fundamental issue that both decoder threads are being scheduled at the same time and pre-empting the d2d rasterizer threads is still happening. It's very interesting that time spent in the decoder threads has gone down so much.

What's also curious is that DwmFlush()/DwmGetCompositionTimingInfo() in this profile can take up to 5-10ms, but this also happens with Silk disabled, it's just moved to the main thread. With 1 physical core / 2 logical cores, these two functions never show up in the profiles.

2) Does this still happen with webm?
This does still happen with webm, but the scheduling priorities are very different than with h264. By default, we use 4 webm decoder threads, but none of the 4 threads are ever executing at the same time. What we actually see is one core totally taken up by 1 of the 4 threads, and that each of the 4 threads swap between each other to take execution time. Thus, one core is still available for the main thread, so that the main thread rarely blocks for more than a couple of ms. I think overall, more time is spent decoding than with h264, but it never takes up both cores at the same time.

3) Is Chrome / IE hitting the flush problem?
Since Chrome/IE do something special if the video is in a background tab, for this test case, I explicitly created two windows. One window running vsynctester.com, the other playing the video, both in the foreground with half the screen. IE played 1080p video using Flash with hardware acceleration disabled. In this test, Chrome, IE, and Firefox all showed roughly the same performance. Some amount of FPS drop in the vsynctester.com test while the video is playing.

Chrome has two decoder threads, each which take ~10-15 ms to render, which is slightly faster than Firefox, which takes ~20 ms to render. In addition, each thread is staggered, so that two threads never execute at the same time. This again frees one one core to do something else. This is forced h264 video.

IE with Flash and hardware acceleration disabled, looks like it has roughly the same pattern as us. It's hard to tell for sure since there are no symbols for the flash player, but the threads look like the same pattern we have: two decoder threads, periodically scheduled and both scheduled at exactly the same time. In addition, in this configuration, the video is actually janky whereas it's not in any other configurations.

IE without Flash installed is limited to 720p video on youtube. With 720p video, IE shows the same pattern of two decoder threads, scheduled at the same time, but each taking only roughly ~2-4 ms. Firefox, with forced 720p video, shows the same pattern as IE, but decoding times seem just a tad longer, more like 3-5ms. However, IE shows a third thread, executing mshtmlmedia.dll, at a very systematic 10ms interval. It's executing CxCodeVideoProcThread::OnWorkItemAsyncCallback -> ConvertNV12ToRGB32. I think then, for 720p video, we're mostly doing what IE is as well, and google results for mshtmlmedia.dll don't show much.

4) Does it make the system bad for other processes?
Can be pretty bad. Also happens with Chrome. Overall though, the system seems a bit more responsive using 1 decoder thread, but it's subjective and could be a placebo. The system is still somewhat slow, but that's expected due to high CPU usage. I think the system feels faster overall with Chrome since the video tab in the background just uses less CPU than we do. Chrome feels like Firefox when I explicitly have two windows open side by side so that the video can't be in the background tab.
Another tidbit, I just tested with IE and forced 1080p video. It has two threads executing in mshtmlmedia.dll and two threads running the decoder and not much else going on. The two threads executing mshtmlmedia.dll, when they are scheduled at roughly the same time as the decoder, usually get pre-empted by the two decoder threads as well.
(In reply to Virtual_ManPL [:Virtual] from comment #95)
> I just wonder how this issue will look like on 144Hz or 120Hz LCD. Probably
> an overkill.

Yes, but I would expect the same thing on Chrome / IE since they too listen to vsync. I think the best performance thing we learned to do is to stop decoding video of background tabs. 

> (In reply to Mason Chang [:mchang] from comment #92)
> I retested it on latest Firefox Nightly 42.0a1 (2015-07-09) with clean new
> fresh profile without any addons (extensions [only Gecko Profiler 1.16.3 is
> installed] and plugins) from
> https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-
> central/

Thanks, yeah both profiles, with and without Silk still have significantly long blocking times of 30-50ms. Thanks again for testing and profiling! I appreciate all the time you took to help diagnose this issue.
(In reply to Mason Chang [:mchang] from comment #102)
> ... I think the best performance thing we learned to do is to stop
> decoding video of background tabs. 

You've mentioned this few times and also filed relevant bugs. Does "stop decoding" also means stop playback? What If I listen to music from a video in a background tab?
(In reply to Avi Halachmi (:avih) from comment #103)
> (In reply to Mason Chang [:mchang] from comment #102)
> > ... I think the best performance thing we learned to do is to stop
> > decoding video of background tabs. 
> 
> You've mentioned this few times and also filed relevant bugs. Does "stop
> decoding" also means stop playback? What If I listen to music from a video
> in a background tab?

It just means stop decoding the "video" portion, not the audio. The audio should keep going.
Also adds a pref that allows us to test how it affects video quality. 

Build here - https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-a96a7996216d

@Anthony - Can you please try this build on some of the machines in the QA lab? There is a new preference "media.wmf.decoder.thread-count" in about:config. A value of -1 means default and lets the host decoder decide how many threads to use. Can you try tuning this preference down to 1 and everything in between (1 and # of cores on machine) and see if video quality is highly affected across a couple of machines? After each setting of the preference, please restart nightly. Thanks!
Attachment #8631869 - Attachment is obsolete: true
Attachment #8631869 - Flags: review?(matt.woodrow)
Flags: needinfo?(anthony.s.hughes)
Sorry, I should explain how to test this. Please test this while playing some youtube videos. Set the preference, see if the video is choppy or if the system significantly slows down / speeds up depending on the preference versus the default -1. Even a result of "can't tell a difference" is good as well. Thanks!
(In reply to Mason Chang [:mchang] from comment #105)
> @Anthony - Can you please try this build on some of the machines in the QA
> lab? 

I'm based in Vancouver and don't have immediate access to the QA lab in Toronto. Kyle, can you please work on Mason's request in comment 105 and 106?
Flags: needinfo?(anthony.s.hughes) → needinfo?(kfung)
We'll find a machine or two (probably one with d2d and one without) on Monday and test this out.
Bas has perhaps seen something similar to this.
I can't really tell a difference after testing it on a few machines. I'm watching 4 different 1080p YouTube videos in separate windows. Video plays back the same and scrolling is fine.
Flags: needinfo?(kfung)
Comment on attachment 8632353 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Thanks for testing Kevin! Looks like this may be ok to land then. Requesting review.
Attachment #8632353 - Flags: review?(matt.woodrow)
Comment on attachment 8632353 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Review of attachment 8632353 [details] [diff] [review]:
-----------------------------------------------------------------

Chris should review this.
Attachment #8632353 - Flags: superreview?(cpearce)
Comment on attachment 8632353 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Review of attachment 8632353 [details] [diff] [review]:
-----------------------------------------------------------------

CODECAPI_AVDecNumWorkerThreads is documented to only work on Win8:

https://msdn.microsoft.com/en-us/library/windows/desktop/hh162722%28v=vs.85%29.aspx

This bug is filed against Windows 7. Does this patch help on Windows != 8? Is MSDN wrong?
(In reply to Chris Pearce (:cpearce) from comment #113)
> Comment on attachment 8632353 [details] [diff] [review]
> Choose number of video decoder threads based on number of cpus
> 
> Review of attachment 8632353 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> CODECAPI_AVDecNumWorkerThreads is documented to only work on Win8:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/hh162722%28v=vs.
> 85%29.aspx
> 
> This bug is filed against Windows 7. Does this patch help on Windows != 8?
> Is MSDN wrong?

Yes this seems to work on Windows 7 SP 1. Also CODECAPI_AVLowLatencyMode seems to work on Windows 7. I see both actually do seem to work and report no errors when setting the attribute. I'm not sure Windows 8 is the only one supported or that's what the docs say. Also see - https://bugzilla.mozilla.org/show_bug.cgi?id=1141139#c3.
Also, from comment 91, this user is on Windows 7 and it seems to fix this issue for him as well.
Comment on attachment 8632353 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Review of attachment 8632353 [details] [diff] [review]:
-----------------------------------------------------------------

I'll take your word on it. Thanks for tracking this down.

::: dom/media/platforms/wmf/WMFVideoMFTManager.cpp
@@ +187,5 @@
>  
>    return decoder.forget();
>  }
>  
> +static int

Style nit:

static int
GetNumOfDecoderThreads()
{
Attachment #8632353 - Flags: superreview?(cpearce) → superreview+
Carrying r+, updated with feedback from comment 116.

Try - https://treeherder.mozilla.org/#/jobs?repo=try&revision=c9ace693e8bb
Attachment #8632353 - Attachment is obsolete: true
Attachment #8632353 - Flags: review?(matt.woodrow)
Attachment #8633774 - Flags: review+
[Tracking Requested - why for this release]:

Re-noming to see if this still requires tracking flags. The original symptoms made this look like a Project Silk bug, but the root cause is due to media thread scheduling. The user was able to reproduce the original issue more frequently with Silk due to overclocking his monitor to 75 hz from the default 60 hz. This, by design, caused 25% more rendering requests as Silk schedules paints according to the vsync rate of the monitor and thus hit the media scheduling issue easier. The fix is to not let the media decoder take up all the available CPUs so that the main thread can still scroll.
tracking-firefox40: + → ?
tracking-firefox41: + → ?
tracking-firefox42: + → ?
Keywords: regression
(In reply to Mason Chang [:mchang] from comment #118)
> Keywords: regression
It was very big regression in scrolling performance and very hard to catch
per Comment 0
> Playing movie isn't the only step to reproduce it as in some cases
> it can happen without it, after too much idling time.
and per Comment 48 & Comment 91
> It can even happen on non movie site, but it's extremely hard to reproduce.
Don't forget also Comment 9, Comment 10 and Comment 11, where the issue occurred only with one tab open (site with no Flash and no HTML5 A/V there). Going fast to VSyncTester website caught how graph look like and how much FPS I get there. It also showed how the issue can be fixed partially, when I minimized and maximized the Firefox window.

(In reply to Mason Chang [:mchang] from comment #118)
> due to overclocking his monitor to 75 hz from the default 60 hz.
There is no need it to be overclocked LCD as I now have 75Mh one and it's visible too with normal CVT mode, compared to CVT-R mode on "overclocked" one. I also tested friends LCDs with 144Mh and 120Mh on my PC, with the same effect.
Keywords: regression
(In reply to Virtual_ManPL [:Virtual] from comment #119)
> (In reply to Mason Chang [:mchang] from comment #118)
> > Keywords: regression
> It was very big regression in scrolling performance and very hard to catch
> per Comment 0
> > Playing movie isn't the only step to reproduce it as in some cases
> > it can happen without it, after too much idling time.

This sounds like a different bug if there is something with too much idling time. I guess it will be very hard to reproduce :( or get a profile.

> and per Comment 48 & Comment 91
> > It can even happen on non movie site, but it's extremely hard to reproduce.
> Don't forget also Comment 9, Comment 10 and Comment 11, where the issue
> occurred only with one tab open (site with no Flash and no HTML5 A/V there).
> Going fast to VSyncTester website caught how graph look like and how much
> FPS I get there. It also showed how the issue can be fixed partially, when I
> minimized and maximized the Firefox window.

This is really odd... I'd still like some STR and maybe if you hit it more frequently once this lands, we can see if the issue is resolved. Was there anything else running on the system at the time? From comment 0 though, it still involved playing a video. If you don't mind, we can open up another bug for the non-video case if you can reproduce something after this patch lands? Thanks again for testing and spending the time to help investigate this!

> 
> (In reply to Mason Chang [:mchang] from comment #118)
> > due to overclocking his monitor to 75 hz from the default 60 hz.
> There is no need it to be overclocked LCD as I now have 75Mh one and it's
> visible too with normal CVT mode, compared to CVT-R mode on "overclocked"
> one. I also tested friends LCDs with 144Mh and 120Mh on my PC, with the same
> effect.

You are correct, sorry I mispoke. But I don't think this is a regression in the traditional sense of "something got slower", versus we're doing more work because we listen to vsync and are keeping up with the system's correct rate rather than choosing 60 by default regardless of the system rate. I also confirmed that we don't backlog / queue up things if the refresh driver / compositor cannot keep up. Even if someone has a 144 Hz monitor, if their system is at 100% CPU usage, we'll limit the rate at which we paint based on when the CPU is available. This was the same without Silk, except we would only hit 100% cpu usage if they couldn't keep up at 60 HZ. Now we can potentially have higher CPU usage on higher rate monitors, but Chrome / IE have fundamentally the same problem with higher rate monitors if they listen to Vsync. If we have higher CPU usage than IE / Chrome at 144 HZ, I would expect that we would also have higher CPU usage at 60 HZ and is something we should fix to optimize that case instead. Does that make sense?
Original patch failed due to reading preferences off main thread. We create the WMFVideoMFTManager on different threads each time, so we were getting assertion failures for reading preferences off main thread. This patch has to create a runnable that runs on the main thread to read the preference, much like [1].

Try - https://treeherder.mozilla.org/#/jobs?repo=try&revision=fee9b6ef92ba

Will ask for another round of review after a successful try run.

[1] https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/wmf/WMFVideoMFTManager.cpp?from=WMFVideoMFTManager.cpp&case=true#126
Attachment #8633774 - Attachment is obsolete: true
(In reply to Mason Chang [:mchang] from comment #120)
> Was there  anything else running on the system at the time?
No. Nothing was running in the background. It were just plain Firefox. But maybe it were some old unloaded leftovers in memory or somewhere of Flash and HTML5 A/V from closed tabs or windows.

(In reply to Mason Chang [:mchang] from comment #120)
> If you don't mind, we can open up another bug for the non-video case
> if you can reproduce something after this patch lands?
If it still will be happening after this patch lands, I will create new bug. Don't worry. I'm sensitive to performance.

(In reply to Mason Chang [:mchang] from comment #120)
> Thanks again for testing and spending the time to help investigate this!
No problem. I'm glad I could help to make our browser better. :)
Comment on attachment 8634260 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Sorry for another round of reviews due to try failures of reading preferences off main thread. See comment 121.
Attachment #8634260 - Flags: review?(cpearce)
Tracking enabled for 40, 41, and 42, do ensure this is fixed, since it looks like the patch failed (comment 121), and video performance is impacted, and therefore customer satisfaction. I think, given the news about FF blocking Flash, that might even entice more users to use FF for video (imho), so we want to deliver reliable performance.
(In reply to jen strickland :jenstrickland from comment #124)
> Tracking enabled for 40, 41, and 42, do ensure this is fixed, since it looks
> like the patch failed (comment 121), and video performance is impacted, and
> therefore customer satisfaction. I think, given the news about FF blocking
> Flash, that might even entice more users to use FF for video (imho), so we
> want to deliver reliable performance.

I'm not a particular fan of uplifting this all the way to beta since the issues occurs without Silk, it just so happened to expose the bug for this user. I'd be ok uplifting to Aurora, but I'd still like to see how this performs across more machines than our limited test cases.

@cpearce - Any opinions on uplifting or how far to uplift?
Flags: needinfo?(cpearce)
I just discussed renaming the title of this bug on IRC with Mason, he suggested renaming this bug to "Video decoder can take all available CPU affecting scrolling performance".

Is this a correct description of it? i.e.:

1. It has nothing to do with "decreasing over time".

2. It has nothing to do with that specific LG monitor other than the fact that it refreshes at 75Hz which happened to be just above the threshold on this system of affecting scroll performance when decoding video without HW acceleration (otherwise, scrolling at 60Hz on this specific system or using stronger CPU or using HW accel to decode video would have avoided this issue - or, as the patch does - don't use all cores for SW decoding).
Flags: needinfo?(bernesb)
I would prefer we didn't uplift this at all.  It only applies to non-60Hz systems with poor CPUs.  I have no data on how many of those we have, but it doesn't feel like a lot.
(In reply to Milan Sreckovic [:milan] from comment #127)
> I would prefer we didn't uplift this at all.  It only applies to non-60Hz
> systems with poor CPUs.  I have no data on how many of those we have, but it
> doesn't feel like a lot.

It's pretty easy to find out these kinds of stats with Telemetry, and in fact, dvander added the refresh rate Telemetry in Aurora 41. Telemetry doesn't report CPU specs yet (bug 1128472)

I'll ask Roberto to post the refresh-rate distribution here.
Note that you can run your own analyses on Telemetry data by following the instructions on http://robertovitillo.com/2015/01/16/next-gen-data-analysis-framework-for-telemetry/.
> See http://nbviewer.ipython.org/gist/vitillo/5a51244b84923c4ed8c9

The conclusion is that only ~3% of Aurora 41 users (with a single monitor) have a refresh rate greater than 65 Hz.
(In reply to Mason Chang [:mchang] from comment #125)
> the issues occurs without Silk, it just so happened to expose the bug for this user
It's true, that the issues were exposed after enabling Silk,
but don't forget the main part of this bug is that the enabled Silk causes lower performance of scrolling in the cases where user doesn't have support for a hardware video acceleration.

(In reply to Avi Halachmi (:avih) from comment #126)
> I just discussed renaming the title of this bug on IRC with Mason, he
> suggested renaming this bug to "Video decoder can take all available CPU
> affecting scrolling performance".
> 
> Is this a correct description of it? i.e.:
I will change it to "Scrolling performance decreased after enabling Silk when hardware video acceleration is disabled".

(In reply to Avi Halachmi (:avih) from comment #126)
> 1. It has nothing to do with "decreasing over time".
Yes.

(In reply to Avi Halachmi (:avih) from comment #126)
> 2. It has nothing to do with that specific LG monitor
Yes.

(In reply to Avi Halachmi (:avih) from comment #126)
> other than the fact
> that it refreshes at 75Hz which happened to be just above the threshold on
> this system of affecting scroll performance
No.
This bug applies to all display refresh rates, even the 60Hz one. See Comment 0, Comment 5, Comment 75 and Comment 86.

(In reply to Avi Halachmi (:avih) from comment #126)
>when decoding video without HW acceleration 
Yes.

(In reply to Avi Halachmi (:avih) from comment #126)
> (otherwise, scrolling at 60Hz on this specific system
No.
This bug applies to all display refresh rates, even the 60Hz one. See Comment 0, Comment 5, Comment 75 and Comment 86.

(In reply to Avi Halachmi (:avih) from comment #126)
> or using stronger CPU
Partially/Maybe/Depends.
The issue is also reproducible with Intel Core 2 Duo E6550 2,33GHz overclocked to nearly 4GHz with changed VCore to make it possible.
But like Mason Chang [:mchang] said, having more cores than 2, like 4 or more, will probably help in this issue.

(In reply to Avi Halachmi (:avih) from comment #126)
> or using HW accel to decode video would have avoided this issue
Yes.
It's bug #1178098.

(In reply to Avi Halachmi (:avih) from comment #126)
> - or, as the patch does - don't use all cores for SW decoding).
Yes.

(In reply to Milan Sreckovic [:milan] from comment #127)
> It only applies to non-60Hz systems
No.
This issue applies to all display refresh rates, even the 60Hz one. See Comment 1, Comment 5, Comment 75 and Comment 86.

(In reply to Milan Sreckovic [:milan] from comment #127)
> with poor CPUs.
I can hardly believe that my CPU which is Intel Core 2 Duo E6550 2,33@3,4GH is the poor one.
I know it's 7 years old CPU, but overclocking it by nearly 50%, gave it some more time to live without changing it. I can play nearly every new game with it on high or medium graphic settings.
The issue is also reproducible with higher overclocking to nearly 4GHz with changed VCore to make it possible.

(In reply to Milan Sreckovic [:milan] from comment #127)
> I have no data on how many of those we have, but it doesn't feel like a lot.
2 cores and 3,4GHz is the more than average CPU per http://store.steampowered.com/hwsurvey and per http://store.steampowered.com/hwsurvey/cpus/ which is CPU with 2 cores and 2,5GHz. Unfortunately it didn't have refresh rates included now, but some years ago the 60Hz was in about 50-60% of all displays.

(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #128)
> the refresh rate Telemetry in Aurora 41.
(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #131)
>(In reply to Roberto Agostino Vitillo (:rvitillo) from comment #129)
>> See http://nbviewer.ipython.org/gist/vitillo/5a51244b84923c4ed8c9
> The conclusion is that only ~3% of Aurora 41 users (with a single monitor)
> have a refresh rate greater than 65 Hz.
Don't forget that it only shows telemetry data from Firefox 41, which can not be reliable compared to our stable Firefox version.
Flags: needinfo?(bernesb)
Summary: Performance of scrolling decreases with browsing time → Scrolling performance decreased after enabling Silk when hardware video acceleration is disabled
(In reply to Virtual_ManPL [:Virtual] from comment #132)
> (In reply to Avi Halachmi (:avih) from comment #126)
> > or using stronger CPU
> Partially/Maybe/Depends.
> The issue is also reproducible with Intel Core 2 Duo E6550 2,33GHz
> overclocked to nearly 4GHz with changed VCore to make it possible.
> But like Mason Chang [:mchang] said, having more cores than 2, like 4 or
> more, will probably help in this issue.

Well, it performs roughly half of recent ULV i3's (e.g. i3-5010u) and only 50% better than bay-trail Atom (z3740) - depending on the task at hand of course, and still, that's roughly where it stand WRT performance.

Using it to decode video in software mode, and without recent CPU extensions such as SSE 4/4.1/AVX/etc, depending on the specific clip properties (resolution, encoding, etc), I'd say it might not be very qualified for the task together with other stuff (scrolling) in parallel, even when overclocked 50% faster.

So indeed it's not about any 60hz threshold, but it's about SW decoding on insufficient hardware, which possibly understandably affects other stuff which needs "real time" priority such as scrolling.
Comment on attachment 8634260 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Review of attachment 8634260 [details] [diff] [review]:
-----------------------------------------------------------------

The number of cores doesn't change at runtime (I hope!). Sync dispatches are a source of bugs, so let's not add any more.

Please instead cache the value in WMFDecoderModule::Init(), and read that cached value in WMFVideoMFTManager::InitInternal(). For example add a static accessor function to WMFDecoderModule that allows you to read the cached number of cores in WMFVideoMFTManager::InitInternal().
Attachment #8634260 - Flags: review?(cpearce) → review-
(In reply to Mason Chang [:mchang] from comment #125)
> @cpearce - Any opinions on uplifting or how far to uplift?

I'd feel better letting this bake a bit, i.e. not uplifting aggressively. Maybe to Aurora, but not to Beta. I'd also feel better if we can get QA to pound on video+scrolling a bit on a range of hardware once this lands.
Flags: needinfo?(cpearce) → qe-verify?
Attachment #8634260 - Attachment is obsolete: true
Attachment #8635039 - Flags: review?(cpearce)
Comment on attachment 8635039 [details] [diff] [review]
Choose number of video decoder threads based on number of cpus

Review of attachment 8635039 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, r+ with printf removed or replaced.

::: dom/media/platforms/wmf/WMFDecoderModule.cpp
@@ +78,5 @@
> +/* static */
> +int
> +WMFDecoderModule::GetNumDecoderThreads()
> +{
> +  printf("Returning number of decoding threads: %d\n", sNumDecoderThreads);

Don't add raw printfs please. You can use our NSPR log code, just copy the definition here into this file and it should work:
https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/wmf/WMFMediaDataDecoder.cpp#15
Attachment #8635039 - Flags: review?(cpearce) → review+
(In reply to Chris Pearce (:cpearce) from comment #137)
> Comment on attachment 8635039 [details] [diff] [review]
> Choose number of video decoder threads based on number of cpus
> 
> Don't add raw printfs please. You can use our NSPR log code, just copy the
> definition here into this file and it should work:
> https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/wmf/
> WMFMediaDataDecoder.cpp#15

Woops sorry about that, leftover debug printf. Didn't mean to do anything there.
Chris - do we need to do the same thing for EME?
Flags: needinfo?(cpearce)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #140)
> Chris - do we need to do the same thing for EME?

Probably a good idea to apply the same fix to gmp-clearkey's WMF decoder. Though it'd be lower priority there since EME videos tend to not appear on pages that scroll.

(In reply to Virtual_ManPL [:Virtual] from comment #141)
> and what about GMP OpenH264?

OpenH264 does not use WMF, so this patch has no affect there.
Flags: needinfo?(cpearce)
https://hg.mozilla.org/mozilla-central/rev/52109dd73a9e
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox42: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
(In reply to Chris Pearce (:cpearce) from comment #142)
> (In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #140)
> > Chris - do we need to do the same thing for EME?
> 
> Probably a good idea to apply the same fix to gmp-clearkey's WMF decoder.
> Though it'd be lower priority there since EME videos tend to not appear on
> pages that scroll.

Do EME videos not play if in a background tab? We can still hit this issue even on pages without a video if one tab has a video playing and another tab is trying to scroll.
Thank you very much!
I'm confirming that this issue is fixed on latest Nightly.

Just see:
Comment 45 - Firefox without this patch and without hardware video acceleration
Comment 145 - Firefox with this patch and without hardware video acceleration
Comment 146 - Firefox with this patch and with hardware video acceleration
Comment 43 - Chrome
and looks like we beat Chrome. Awesome job.
Attachment #8636030 - Attachment description: 'final patch' Firefox 42.0a1 (2015-07-20) VSyncTester+movie playing in background [hardware video acceleration].png → 'final patch' Firefox 42.0a1 (2015-07-20) VSyncTester+movie playing in background [without hardware video acceleration].png
Attachment #8636030 - Attachment filename: irefox 42.0a1 (2015-07-20) VSyncTester+movie playing in background [hardware video acceleration].png → 2.0a1 (2015-07-20) VSyncTester+movie playing in background [without hardware video acceleration].png
Mason, do you have plans to uplift this patch to 40 & 41? Thanks
Flags: needinfo?(mchang)
From comment 127 and 135, I think we're better off not uplifting this. This specific issue isn't unique to Silk and occurs without Silk.
Flags: needinfo?(mchang)
But don't forget that enabled Silk worsens the performance of scrolling on Firefox without hardware video acceleration used on CPU with less than 4 CPU threads, that's why I named it a regression.
(In reply to Virtual_ManPL [:Virtual] from comment #150)
> But don't forget that enabled Silk worsens the performance of scrolling on
> Firefox without hardware video acceleration used on CPU with less than 4 CPU
> threads, that's why I named it a regression.

I would also add only if they have a monitor that is greater than 60 hz. If they have a 60 hz monitor, it isn't really a regression.
(In reply to Virtual_ManPL [:Virtual] from comment #152)
> This bug applies to all display refresh rates, even the 60Hz one. See
> Comment 0, Comment 5, Comment 75, Comment 86 and Comment 132.

Yes it does, but would only count as a regression if they have a monitor greater than 60 hz. At least the root cause of this bug, with the number of video decoding thread, still occurs with Silk disabled and 60 hz monitors. If another issue comes up with scrolling with Silk, I'd prefer to open another bug please.

If a user has a 60 hz monitor, Silk doesn't matter in this particular case. The root cause of the WMF video decoder threads taking all the CPUs can still happen.
(In reply to Mason Chang [:mchang] from comment #153)
> (In reply to Virtual_ManPL [:Virtual] from comment #152)
> > This bug applies to all display refresh rates, even the 60Hz one. See
> > Comment 0, Comment 5, Comment 75, Comment 86 and Comment 132.
> Yes it does, but would only count as a regression if they have a monitor
> greater than 60 hz. At least the root cause of this bug, with the number of
> video decoding thread, still occurs with Silk disabled and 60 hz monitors.
(In reply to Mason Chang [:mchang] from comment #153)
> If a user has a 60 hz monitor, Silk doesn't matter in this particular case.
Odd. In my tests, I had snappier scrolling and more FPS with Silk disabled, comparing it to with Silk enabled, on VSyncTester website with movie playing in background, on Firefox without hardware video acceleration, even in 60Hz. But I only tested this about 2-5 times, so the results can be not authoritative and reliable.
(In reply to Mason Chang [:mchang] from comment #144)
> (In reply to Chris Pearce (:cpearce) from comment #142)
> > (In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #140)
> > > Chris - do we need to do the same thing for EME?
> > 
> > Probably a good idea to apply the same fix to gmp-clearkey's WMF decoder.
> > Though it'd be lower priority there since EME videos tend to not appear on
> > pages that scroll.
> 
> Do EME videos not play if in a background tab? We can still hit this issue
> even on pages without a video if one tab has a video playing and another tab
> is trying to scroll.

Good point. EME videos can play in a background tab. We'll need to make this change in gmp-clearkey, and get Adobe to make the same change in their WMF decoder.
Based on comment 149, I have marked 40 and 41 as wontfix. We'll let this fix ride the trains.
status-firefox40: affected → wontfix
status-firefox41: affected → wontfix
(In reply to Chris Pearce (:cpearce) from comment #155)
> Good point. EME videos can play in a background tab. We'll need to make this
> change in gmp-clearkey, and get Adobe to make the same change in their WMF
> decoder.

It probably makes sense to pass the number of CPUs to use into GMP so we can have one version of this logic.

If we consider the case where one EME video is playing and one non-EME video is playing we can still get to the situation where the software compositor gets starved. Ideally we want the OS scheduler to do the right thing for us but I don't know if there is a better way to do that on Windows.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: