Closed
Bug 1299860
Opened 8 years ago
Closed 8 years ago
Linux: Window/screensharing (and gUM) on 51 only generates a frame or two due to layers acceleration
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla52
Tracking | Status | |
---|---|---|
firefox50 | --- | unaffected |
firefox51 | --- | disabled |
firefox52 | --- | fixed |
People
(Reporter: jesup, Assigned: nical)
References
Details
(Keywords: regression)
Attachments
(4 files, 3 obsolete files)
This is fine in 49 and 50. On Fedora 22 with 51 I'm seeing a frame (or maybe two) come in for window and screensharing, then it stops. (With screensharing, it seems to bring in 2ish frames and then alternated between them) Perhaps the rework to MediaEngine*?
Comment 2•8 years ago
|
||
Wfm on OSX, but I don't have Fedora. No idea. Does this fiddle work for you? https://jsfiddle.net/3xytpne5/ Could you do a mozregression to narrow it down?
Flags: needinfo?(jib) → needinfo?(rjesup)
Reporter | ||
Comment 3•8 years ago
|
||
A bit more info; Screensharing - when the mouse moves, the screen flickers between correct (with mouse ptr) and a frame that looks like it was grabbed at the start of the capture. Stationary mouse, it calms down. Window sharing: frozen after first frame, no updates -- until you resize or move the window. After that it works fine.
Flags: needinfo?(rjesup)
Reporter | ||
Comment 4•8 years ago
|
||
Also: the fiddle won't work for me. NotALlowed error. I saved the HTML and the JS and installed it on my local server, and browsed there (https of course), and it works. perhaps jsfiddle has iframes?
Comment 5•8 years ago
|
||
Yes, you need to add fiddle.jshell.net (not jsfiddle.net) to the allowed_domains.
Comment 6•8 years ago
|
||
Nico -- Can you work with jesup and jib to find out what's going on here? (I believe this should repro on any Linux system.) I'd like to assign this bug to you if you can repro it on your Linux box. Thanks!
Flags: needinfo?(ngrunbaum)
Comment 7•8 years ago
|
||
(In reply to Maire Reavy [:mreavy] from comment #6) > Nico -- Can you work with jesup and jib to find out what's going on here? > (I believe this should repro on any Linux system.) I'd like to assign this > bug to you if you can repro it on your Linux box. Thanks! Works for me on my Ubuntu 14.04 box, and on my Ubuntu 16.04 box. I used :jib's fiddle but added a youtube embed. Both were built off inbound@e0d755ab4cbd. I'll give it a look on Fedora.
Flags: needinfo?(ngrunbaum)
Reporter | ||
Comment 8•8 years ago
|
||
Note: the fps monitor I added shows ~20fps or more even though the image isn't changing (until I resize). Note: moving it doesn't unfreeze it.
Comment 9•8 years ago
|
||
I can't reproduce it in Fedora 24. I will give Fedora 22 a shot.
Flags: needinfo?(na-g)
Comment 10•8 years ago
|
||
(In reply to Nico Grunbaum [:ng] from comment #9) > I can't reproduce it in Fedora 24. I will give Fedora 22 a shot. I am not having any luck reproducing it on 22 either.
Reporter | ||
Comment 11•8 years ago
|
||
This is being seen in regular gUM as well (though not as consistently). You'll get maybe 2 frames, and it will flip between them. Stopping the video element playback and resuming it will get different frames, but still broken. In both window capture and webcam capture cases, the "Snapshot" button shows that the frames are being captured correctly. Also, the fps counter shows that we're getting frames and the <video> element thinks it's displaying them. Very likely a regression due to the "don't buffer frames in MSG" patch. bug 1201363
Blocks: 1201363
status-firefox50:
--- → unaffected
status-firefox51:
--- → affected
Flags: needinfo?(na-g) → needinfo?(ctai)
Comment 12•8 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #11) > This is being seen in regular gUM as well (though not as consistently). > You'll get maybe 2 frames, and it will flip between them. Stopping the > video element playback and resuming it will get different frames, but still > broken. In both window capture and webcam capture cases, the "Snapshot" > button shows that the frames are being captured correctly. Also, the fps > counter shows that we're getting frames and the <video> element thinks it's > displaying them. > > Very likely a regression due to the "don't buffer frames in MSG" patch. bug > 1201363 Hi, Randell, What is the webpage you used to repo this bug? Can you point me out? Thanks.
Flags: needinfo?(ctai)
Reporter | ||
Comment 13•8 years ago
|
||
> Hi, Randell, > What is the webpage you used to repo this bug? Can you point me out? Thanks. https://mozilla.github.io/webrtc-landing/gum_test.html
Comment 14•8 years ago
|
||
Comment 15•8 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #13) > > Hi, Randell, > > What is the webpage you used to repo this bug? Can you point me out? Thanks. > > https://mozilla.github.io/webrtc-landing/gum_test.html I have tried the latest central on Ubuntu with the following steps. Please correct me if anything wrong. 1. Open nightly and go to webpage: https://mozilla.github.io/webrtc-landing/gum_test.html 2. Click screen and click snapshot. 3. Get the result like attachment 8792737 [details] The result looks good to me. Am I wrong? I also try the gUM and screen sharing too.
Comment 16•8 years ago
|
||
Updated•8 years ago
|
Flags: needinfo?(rjesup)
Reporter | ||
Comment 17•8 years ago
|
||
(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #15) > (In reply to Randell Jesup [:jesup] from comment #13) > > > Hi, Randell, > > > What is the webpage you used to repo this bug? Can you point me out? Thanks. > > > > https://mozilla.github.io/webrtc-landing/gum_test.html > > I have tried the latest central on Ubuntu with the following steps. Please > correct me if anything wrong. > 1. Open nightly and go to webpage: > https://mozilla.github.io/webrtc-landing/gum_test.html > 2. Click screen and click snapshot. > 3. Get the result like attachment 8792737 [details] > > The result looks good to me. Am I wrong? > I also try the gUM and screen sharing too. I never see it with a Screen share, only with Window (and it always happens *for me* on Window. (I didn't try Application). Nico has been unable to reproduce the Window issue with Ubuntu or Fedoran (though likely in a VM). I see it *sometimes* with Video. These all point to timing/ordering as triggers.
Flags: needinfo?(rjesup)
Comment 18•8 years ago
|
||
... (In reply to Randell Jesup [:jesup] from comment #17) > I never see it with a Screen share, only with Window (and it always happens > *for me* on Window. (I didn't try Application). Nico has been unable to > reproduce the Window issue with Ubuntu or Fedoran (though likely in a VM). > > I see it *sometimes* with Video. > > These all point to timing/ordering as triggers. I was only testing screen sharing. Those were real metal installs on a machine with Intel integrated graphics (whatever is on a i5-4960), if that maters. I can retry window sharing with Ubuntu 16.04 easily.
Comment 19•8 years ago
|
||
(In reply to Nico Grunbaum [:ng] from comment #18) > ... > (In reply to Randell Jesup [:jesup] from comment #17) > > I never see it with a Screen share, only with Window (and it always happens > > *for me* on Window. (I didn't try Application). Nico has been unable to > > reproduce the Window issue with Ubuntu or Fedoran (though likely in a VM). > > > > I see it *sometimes* with Video. > > > > These all point to timing/ordering as triggers. > > I was only testing screen sharing. Those were real metal installs on a > machine with Intel integrated graphics (whatever is on a i5-4960), if that > maters. I can retry window sharing with Ubuntu 16.04 easily. I can't repo it on Mac and Ubuntu with Window case. :( @Randell, That will be great if you can revert to [1](the parent commit of stop-buffering bug) since you can repo it 100%. [1]: http://searchfox.org/mozilla-central/commit/f226c252d49057abbbacc4fc2006623da2779aac
Flags: needinfo?(rjesup)
Reporter | ||
Comment 20•8 years ago
|
||
First broken Nightly is 8/20: http://archive.mozilla.org/pub/firefox/nightly/2016/08/2016-08-20-03-02-24-mozilla-central/firefox-51.0a1.en-US.linux-x86_64.tar.bz2 hg log -r 23c2ec5544b9e0a74a047b87b594e4c36a8fe95c:f97a056ae6235de7855fd8aaa04fb1c8d183bd06 Confirmed a couple of times... but I don't see *any* media code changing there. Maybe it is compositor? (Nical - note that we also sometimes see this on getUserMedia video as well, not just Window sharing.) Last possibility would be some perf-triggered bug introduced earlier, and something changed perf/timing on 8/20.
Flags: needinfo?(rjesup) → needinfo?(nical.bugzilla)
Reporter | ||
Comment 21•8 years ago
|
||
I'm regression-range testing within that timeframe on local inbound builds
Reporter | ||
Comment 22•8 years ago
|
||
Ok, the regression range is wrong. A given run of firefox will either show this every time, or not show it at all, no matter how many times you start and stop the test. Combine that with it happening (in most builds) maybe 1/3 to 1/8 runs, and it mis-identified the range. The 7/15 Nightly definitely shows it.
Reporter | ||
Comment 23•8 years ago
|
||
happens in 7/1 and 6/15 nightlies.... But: for added confusion, the auto-updater causes me to jump forward to 9/20 if I let it run too long before updating! So all my tests are invalid :-(
Reporter | ||
Comment 24•8 years ago
|
||
Works in 8/5, fails in 8/24, ??? in 8/15 (I think works; ETOOMANYTESTS)
Reporter | ||
Comment 25•8 years ago
|
||
8/20 fails. IIRC 8/19 worked, but checking again, since nothing in that range looked suspicious
Comment 26•8 years ago
|
||
On Ubuntu Desktop 64bit 16.0.4.1 running the 8/24 via: mozregression --launch '2016-08-24' --arg 'https://mozilla.github.io/webrtc-landing/gum_test.html' When I try window sharing the entire Unity desktop session freezes up until I kill FF from the command line.
Reporter | ||
Comment 27•8 years ago
|
||
10 runs with 8/19 Nightly, no failures. This is the same range I gave earlier, apparently that does match my results. As for Unity desktop -- file a new bug, including X version number. Also: try gdbing it from the command line (using a local build, or with some pain using symbols.py in .gdbinit). See what thread is wedged in an X call.
Reporter | ||
Comment 28•8 years ago
|
||
Basically nothing in media/* or dom/media landed there (except a minor JSEP thing we aren't touching in gUM/playback). There was a small change to dom/html/HTMLTrackElement.cpp Interesting... one real change: gfx/thebes/gfxPlatformGtk.h added AccelerateLayersByDefault() with 'return true' for NIGHTLY_BUILDs..... Bug 594876 Nical - this was your landing. I'll try backing out that change to see
Blocks: ogl-linux-beta
Reporter | ||
Comment 29•8 years ago
|
||
Confirmed. It's the default-acceleration. -> Graphics
Component: WebRTC: Audio/Video → Graphics
Reporter | ||
Comment 30•8 years ago
|
||
Reporter | ||
Comment 31•8 years ago
|
||
Since this is "nightly only", it may not affect 51 Aurora, note.
No longer blocks: 1201363
Rank: 13
OS: Unspecified → Linux
Priority: P1 → --
Summary: Window/screensharing on 51 only generates a frame or two → Linux: Window/screensharing (and gUM) on 51 only generates a frame or two due to default acceleration
Comment 32•8 years ago
|
||
:jesup, could you be having e10s disabled on your nightly build? I've noticed a very different behaviour of accelerated layers with e10s on or off.
Assignee | ||
Comment 33•8 years ago
|
||
The plan is to let layers acceleration enabled by default on in nightly (and aurora maybe, not sure), but not in beta and release until we have a good driver blocklist story on linux. Right now we are at the stage where we build up the list of hardware where accelerated compositing works reliably, but it won't ride the trains and ship just yet. If this is only driver issue we just need to make sure to update the blocklist (this is pending on a patch from :acomminos that fixes the blocklist code on linux, should land soon but I don't know what bug is tracking it). It'm surprised that a driver issue happens on both linux and windows, though. I can't reproduce it on the two computers I have handy. You can toggle gl layers on linux using the pref "layers.acceleration.disabled" (need to restart the browser) to check that this is the problem.
Flags: needinfo?(nical.bugzilla)
Summary: Linux: Window/screensharing (and gUM) on 51 only generates a frame or two due to default acceleration → Linux: Window/screensharing (and gUM) on 51 only generates a frame or two due to layers acceleration
Assignee | ||
Comment 34•8 years ago
|
||
(In reply to Nicolas Silva [:nical] from comment #33) > It'm surprised that a driver issue happens on both linux and windows, though. nevermind, I misread the bug title.
Reporter | ||
Comment 35•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #32) > :jesup, could you be having e10s disabled on your nightly build? > > I've noticed a very different behaviour of accelerated layers with e10s on > or off. In fact it does not appear to happen if I turn on e10s. Of course, it was not 100% in non-e10s, so presumably there's some timing or other sensitivity which e10s might happen to avoid.
Comment 36•8 years ago
|
||
Maybe related to bug 1304347 then... different outcome but same underlying issue?
See Also: → 1304347
Assignee | ||
Comment 37•8 years ago
|
||
Randell, could you try this patch out and see what shows up in stdout ?
Assignee | ||
Comment 38•8 years ago
|
||
Comment 39•8 years ago
|
||
Setting status-firefox51 to disabled since IIUC, this is a nightly-only regression.
Assignee | ||
Comment 40•8 years ago
|
||
This should fix the issue.
Attachment #8793751 -
Attachment is obsolete: true
Attachment #8793763 -
Attachment is obsolete: true
Attachment #8797137 -
Flags: review?(bas)
Assignee | ||
Comment 41•8 years ago
|
||
(In reply to Nicolas Silva [:nical] from comment #40) > Created attachment 8797137 [details] [diff] [review] > Don't set the ImageBridge and VRManager backends when creating secondary > widgets. Randell, could you try this patch out when you have some time? Thanks!
Flags: needinfo?(rjesup)
Updated•8 years ago
|
Attachment #8797137 -
Flags: review?(bas) → review+
Assignee | ||
Comment 42•8 years ago
|
||
Attachment #8797137 -
Attachment is obsolete: true
Assignee | ||
Comment 43•8 years ago
|
||
Randell just confirmed on irc that the patch seems to fix the issue.
Flags: needinfo?(rjesup)
Comment 44•8 years ago
|
||
Pushed by nsilva@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/9fbc16390ef7 Don't use the compositor backend of a popup with ImageBridge and VRManager. r=Bas
Comment 45•8 years ago
|
||
backed out for bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=37188541&repo=mozilla-inbound
Flags: needinfo?(nical.bugzilla)
Comment 46•8 years ago
|
||
Backout by cbook@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/8cca96652000 Backed out changeset 9fbc16390ef7 for bustage on a CLOSED TREE
Comment 47•8 years ago
|
||
Pushed by nsilva@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/72c643ed82ba Don't use the compositor backend of a popup with ImageBridge and VRManager. r=Bas
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(nical.bugzilla)
Comment 48•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/72c643ed82ba
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment 49•8 years ago
|
||
(In reply to Nicolas Silva [:nical] from comment #33) > The plan is to let layers acceleration enabled by default on in nightly (and > aurora maybe, not sure), but not in beta and release until we have a good > driver blocklist story on linux. Right now we are at the stage where we > build up the list of hardware where accelerated compositing works reliably, > but it won't ride the trains and ship just yet. If this is only driver issue > we just need to make sure to update the blocklist (this is pending on a > patch from :acomminos that fixes the blocklist code on linux, should land > soon but I don't know what bug is tracking it). Bug 1294232 - Improve GLX blocklisting on Linux/X11
Comment 52•6 years ago
|
||
Further testing revealed that on macOS High Sierra 10.13 and on Ubuntu 18.04 the issue is still reproducible since only 5-8 FPS are displayed during screen and window sharing on getUserMedia test page. Please note, that one Mac the mouse cursor is also barely visible during window sharing mode on the latest Nightly build 62.0a1.(2018-06-21). Nicolas, should I log a new bug given the above mentioned results?
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 53•6 years ago
|
||
> Nicolas, should I log a new bug given the above mentioned results?
Yes, this bug was closed a while ago, so it's probably a different issue.
Flags: needinfo?(nical.bugzilla)
Comment 54•6 years ago
|
||
Submitted Bug 1470854 for further investigation regarding the mentioned issue in Comment 52.
You need to log in
before you can comment on or make changes to this bug.
Description
•