Closed Bug 1222821 Opened 9 years ago Closed 9 years ago

A second browser window with playing HTML5 Youtube video makes main browser window very laggy

Categories

(Core :: Graphics: Layers, defect)

45 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jonasthiem, Unassigned)

References

Details

(Keywords: perf)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20151107030439 Steps to reproduce: 1. Open up a second browser window 2. Open up youtube in the second browser window 3. Start playing a video in the second browser window, and make sure Adobe Flash is disabled (so HTML5 playback is used) 4. Open multiple tabs in the main window with various regular sites (I used arstechnica.com, golem.de and others). While the video is playing (not paused/buffering), try to scroll up/down and navigate pages in the main window Actual results: Main window is very laggy and unresponsive even with just scrolling and even with advanced pan and zoom enabled. It seems to react to any sort of input events only a few times a second. As soon as you pause the playback of the youtube in the second window, the main window will instantly become perfectly responsive Expected results: Main window stays responsive
The effect is amplified if you have some other application running in the background that uses a bit of CPU. The video will always play perfectly smooth, but while it does the main window will be incredibly unresponsive. The video tab itself is NOT affected, you can scroll up/down perfectly and smoothly in the tab where the playing youtube video is contained in the second browser window
Component: Untriaged → Audio/Video
Keywords: perf
Product: Firefox → Core
Component: Audio/Video → Audio/Video: Playback
Wonder if this could be related to bug 1222308.
See Also: → 1222308
CPU info: jonas@cyberman:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz stepping : 7 microcode : 0x29 cpu MHz : 2999.902 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt bugs : bogomips : 4983.73 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz stepping : 7 microcode : 0x29 cpu MHz : 2999.902 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt bugs : bogomips : 4983.73 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz stepping : 7 microcode : 0x29 cpu MHz : 2999.902 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt bugs : bogomips : 4983.73 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz stepping : 7 microcode : 0x29 cpu MHz : 2999.902 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt bugs : bogomips : 4983.73 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Just as a note, since only the main window without the video of firefox is affected and the video page itself in the external window still scrolls very smoothly (and desktop/window manager doesn't freeze either) I doubt it's just my machine getting exhausted.. although I guess it could be some weird threading/multi-core issue, who knows
Your CPU should be plenty fast enough. Can you retry a nightly build with bug 1222308 fixed?
Which nightly build would that be? It's still as badly broken as it used to be in yesterday's 45.0a1 (2015-11-19).
That nightly should be new enough to have the fix. Could be e10s or a compositor bandwidth issue. Can you please try with a 'non-e10s window' from the hamburger menu? That will help us eliminate one of those.
I disabled "Enable multi-process Nightly", restarted firefox and tried again. Same issue, a second window with youtube playing makes the main window lag horribly (while the youtube window itself is happy). This person seems to see the same problem on Windows (I'm on Linux) https://bugzilla.mozilla.org/show_bug.cgi?id=1226401
I can confirm layers.acceleration.disabled=true fixes it for me as well.
Ok, sounds like a graphics issue. Matt, can you offer an opinion?
Component: Audio/Video: Playback → Graphics: Layers
Flags: needinfo?(matt.woodrow)
I filed bug 1226401 but my issues are a bit worse. I have tested it with Firefox 43 and 46(with e10s and APZ) on Windows 10 with a Nvidia GTX460 and an Intel Core i5 760 @ 2,8GHz. Even with a new profile, a single window, no addons or plugins, and no tabs except one about:newtab the whole Firefox lags when I type something in the awesome bar or search bar. With layers.acceleration.disabled=true or 32-bit Firefox this doesn't happen at all. Testcase: If I click into the awesome bar or search bar and hold a button on my keyboard, the characters are appearing with a delay compared to layers.acceleration.disabled=true. It seems like the characters are appearing in pairs of a about 5, while they appear one by one (and faster) with layers.acceleration.disabled=true or 32-bit Firefox. Jonas, could you test this too? Compare it with layers.acceleration.disabled=true. First I also fought it's just a issue with videos and scrolling. Lagging video or scrolling is much more visible than a lagging interface while typing. Maybe our issues are the same.
Flags: needinfo?(jonasthiem)
Nope that works perfectly fine for me. What I'm seeing is purely limited to 2+ windows when at least one processing-heavy task (e.g. youtube video) is active in one of them. With one window or multiple ones without much dynamic content, I see no problems. I have a weak Intel GPU, so I doubt it's because my machine is notably faster or anything.
Flags: needinfo?(jonasthiem)
Of course it could still be the same problem, maybe my drivers just behave a bit better for some reason..
Setting media.hardware-video-decoding.enabled=false reduces the load on the GPU by decoding with the CPU. That may give better results. I'd be interested to know how other browsers perform on the same machine. Can you actually see the video playing in the background or is it obscured by other windows?
Closing for lack of follow-up.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(matt.woodrow)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.