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)

51 Branch
Unspecified
Linux
defect
Not set
major

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*?
Jan-Ivar, any ideas?
Rank: 13
Flags: needinfo?(jib)
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)
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)
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?
Yes, you need to add fiddle.jshell.net (not jsfiddle.net) to the allowed_domains.
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)
(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)
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.
I can't reproduce it in Fedora 24. I will give Fedora 22 a shot.
Flags: needinfo?(na-g)
(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.
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
Flags: needinfo?(na-g) → needinfo?(ctai)
(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)
> 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
(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.
Flags: needinfo?(rjesup)
(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)
...
(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.
(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)
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)
I'm regression-range testing within that timeframe on local inbound builds
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.
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 :-(
Works in 8/5, fails in 8/24, ??? in 8/15 (I think works; ETOOMANYTESTS)
8/20 fails.  IIRC 8/19 worked, but checking again, since nothing in that range looked suspicious
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.
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.
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
Confirmed.  It's the default-acceleration.

-> Graphics
Component: WebRTC: Audio/Video → Graphics
Attached file gfx.info
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
: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.
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
(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.
(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.
Maybe related to bug 1304347 then... different outcome but same underlying issue?
See Also: → 1304347
Randell, could you try this patch out and see what shows up in stdout ?
Setting status-firefox51 to disabled since IIUC, this is a nightly-only regression.
Assignee: nobody → nical.bugzilla
Version: 49 Branch → 51 Branch
This should fix the issue.
Attachment #8793751 - Attachment is obsolete: true
Attachment #8793763 - Attachment is obsolete: true
Attachment #8797137 - Flags: review?(bas)
(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)
Attachment #8797137 - Flags: review?(bas) → review+
Randell just confirmed on irc that the patch seems to fix the issue.
Flags: needinfo?(rjesup)
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
backed out for bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=37188541&repo=mozilla-inbound
Flags: needinfo?(nical.bugzilla)
Backout by cbook@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8cca96652000
Backed out changeset 9fbc16390ef7 for bustage on a CLOSED TREE
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
Flags: needinfo?(nical.bugzilla)
https://hg.mozilla.org/mozilla-central/rev/72c643ed82ba
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
(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
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)
> 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)
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.