1053264 - Mouse cursor flickers after activating screensharing on Windows

Status: VERIFIED FIXED

(Core :: WebRTC, defect)

Description

[Paul Silaghi, QA [:pauly]]

STR:
1. Open http://queze.net/goinfre/ff_gum_test.html
2. Click on 'Screen'
3. Choose 'Entire screen' in the pop up and press 'Share selected items' button

AR:
The mouse cursor is flickering
Not repro on Mac, Linux

Comment 1

[Paul Silaghi, QA [:pauly]]

34.0a1 (2014-08-13), Win 7 x64

Comment 2

[Florian Quèze [:florian]]

I mentioned this when filing bug 1043350, but it looks like that bug got resolved without addressing the blinking cursor issue, so I'm not duping it.

Comment 3

[Maire Reavy [:mreavy]]

Any ideas what may be causing this?  It (the flickering) seems to be worse when you have a second monitor attached.  Anyone able to take ownership of this bug?  It's annoying enough that I'd like to fix it soon and possibly uplift it (depending on how extensive the fix is).

Comment 4

[Gian-Carlo Pascutto [:gcp]]

I'll investigate.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Most references I find to this problem say it happens if you hold the GDI locked for too long, when a software drawn cursor is in action. From looking at the code, it keeps a handle on the desktop DC forever, so that's plausible, on the other hand I'd be surprised if my system couldn't deal with a hardware accelerated cursor. 

I also checked the current capture code vs that in Chrome, and it's essentially identical in the relevant functions. I don't see flicker in Chrome though.

Maybe we're capturing at an insane FPS?

Comment 6

[Gian-Carlo Pascutto [:gcp]]

I put some code to force releasing/reacquiring the DCs on every frame, but that didn't help. I also see quite a bit of CPU usage even on my fast desktop, so I'm going to investigate the FPS angle.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

As far as I can see we don't limit the FPS at all, i.e. we call this function:
http://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc#803
in a WebRTC thread wrapper, at high priority. The thread wapper just loops on that call. So we're effectively hogging the (one?) CPU capturing as fast as we can.

I added some simple FPS limiting/CPU usage limiting, but I still saw flicker...looking further...

Comment 8

[Gian-Carlo Pascutto [:gcp]]

The previous searching I did on this lead me totally in the wrong direction on a wild goose chase. On top of that, the flicker on my main desktop is subtle (maybe due to the GTX670, i.e. a pretty beefy card) and sometimes it syncs with what I assume is the monitor refresh and you can't see it - that made tracing this harder. My Mozilla workstation has a "workstation" card (i.e. a very very slow one, K600) and there it's much more obvious, but I still erroneously though I'd found something only to get a cold shower half an hour later.

So, this is background reading for the *actual* problem:
http://technet.microsoft.com/en-us/magazine/2009.02.windowsconfidential.aspx
(and note that due to shadows etc hardware cursors are never used anyway)

The solution was then in a user comment on the bottom of the MSDN page:
http://msdn.microsoft.com/en-us/library/dd183370(v=vs.85).aspx
Observing that DWM based desktop composition in Vista+ seems to remove the need to add the CAPTUREBLT flag or treat layered windows specifically. See also for example http://stackoverflow.com/questions/1193335/screen-capture-ignores-some-windows which confirms this by observing it in the opposite direction.

I've verified that on my Windows 7 machine layered windows (e.g. foo_osd in foobar2000) *are* indeed correctly captured when in Aero mode even without that flag set.

(On a related note, that not disabling Aero mode as we did in Bug 1043350 might cause some applications using DirectDraw etc not to show up on certain versions of Windows either. But if Aero is disabled for any reason, we have to use CAPTUREBLT anyway, and even disabling Aero mode wouldn't generally solve that problem as far as I understand.)

So, based on all that background, my patch removes the CAPTUREBLT flag if we probe and confirm we are currently in DWM/Aero mode. This will remove the cursor flicker. If we are not in Aero mode or on a previous version of Windows without DWM (XP), we'll continue as before.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 1. no-captureblt-on-aero

Comment 10

[Gian-Carlo Pascutto [:gcp]]

https://tbpl.mozilla.org/?tree=Try&rev=7df7db3fea2e

Comment 11

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/abda4b975d58

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/abda4b975d58

Comment 13

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 8482341 [details] [diff] [review]
Patch 1. no-captureblt-on-aero

Approval Request Comment
[Feature/regressing bug #]: Bug 983504 - Basic WebRTC screensharing support
[User impact if declined]: Mouse cursor will flicker during screensharing.
[Describe test coverage new/current, TBPL]: Landed on m-c a few days ago.
[Risks and why]: At worst, some windows may not show up on the shared screen.
[String/UUID change made/needed]: N/A

Comment 14

[Paul Silaghi, QA [:pauly]]

Verified fixed 35.0a1 (2014-09-09) Win 7 x64

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8482341 [details] [diff] [review]
Patch 1. no-captureblt-on-aero

Approved for Beta and Aurora

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7fdabeeb576f
https://hg.mozilla.org/releases/mozilla-beta/rev/5638564e0d94

Comment 17

[Cristina Madaras, QA [:CristinaM]]

Reproduced the issue on Windows 7 64bit:
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:34.0) Gecko/20100101 Firefox/34.0
BuildId: 20140814005302

Verified as fixed on Beta 33.0b3
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build Id: 20140911191954

I'll verify this on Aurora when build will be available.

Comment 18

[Cristina Madaras, QA [:CristinaM]]

No pop-up for sharing the items is displayed.
I changed media.getusermedia.screensharing.allowed_domains = queze.net in about:config, but when I choose 'Screen', 'PERMISSION_DENIED' message is displayed in the page.
Reproducible on latest Aurora and latest Nightly.
Any ideas what may causing this?

Regression window:
Nightly (2014-09-10) Build Id: 20140910030204 -good, the pop-up is displayed and I'm able to share the screen
Nightly (2014-09-11) BuildId: 20140911064110 - bad, no pop-up is displayed

Comment 19

[Gian-Carlo Pascutto [:gcp]]

Maybe bug 1063730?

Comment 20

[Florian Quèze [:florian]]

Screensharing now requires an https URL. You can use https://people.mozilla.org/~fqueze2/webrtc/ instead.

Comment 21

[Cristina Madaras, QA [:CristinaM]]

Verified as fixed on Aurora under Windows 7 x64bit.
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build Id: 20140915004005

I used the URL from comment20, the doorhanger is displayed and the screen can be shared.