Mouse cursor flickers after activating screensharing on Windows

VERIFIED FIXED in Firefox 33

Status

()

defect
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: pauly, Assigned: gcp)

Tracking

unspecified
mozilla35
x86_64
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox33 verified, firefox34 verified, firefox35 verified)

Details

()

Attachments

(1 attachment)

Reporter

Description

5 years ago
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
Reporter

Comment 1

5 years ago
34.0a1 (2014-08-13), Win 7 x64
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.
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).
Flags: needinfo?(rskalish)
Flags: needinfo?(rjesup)
Flags: needinfo?(linuxwolf)
Flags: needinfo?(gpascutto)
Whiteboard: [screensharing-uplift]
Assignee

Comment 4

5 years ago
I'll investigate.
Assignee: nobody → gpascutto
Flags: needinfo?(rskalish)
Flags: needinfo?(rjesup)
Flags: needinfo?(linuxwolf)
Flags: needinfo?(gpascutto)
Assignee

Comment 5

5 years ago
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?
Assignee

Comment 6

5 years ago
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.
Assignee

Comment 7

5 years ago
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...
Assignee

Comment 8

5 years ago
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.
Assignee

Comment 9

5 years ago
Attachment #8482341 - Flags: review?(jmathies)

Updated

5 years ago
Attachment #8482341 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/abda4b975d58
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Assignee

Comment 13

5 years ago
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
Attachment #8482341 - Flags: approval-mozilla-beta?
Attachment #8482341 - Flags: approval-mozilla-aurora?
Reporter

Comment 14

5 years ago
Verified fixed 35.0a1 (2014-09-09) Win 7 x64
Status: RESOLVED → VERIFIED
Comment on attachment 8482341 [details] [diff] [review]
Patch 1. no-captureblt-on-aero

Approved for Beta and Aurora
Attachment #8482341 - Flags: approval-mozilla-beta?
Attachment #8482341 - Flags: approval-mozilla-beta+
Attachment #8482341 - Flags: approval-mozilla-aurora?
Attachment #8482341 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
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.
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
Assignee

Comment 19

5 years ago
Maybe bug 1063730?
Screensharing now requires an https URL. You can use https://people.mozilla.org/~fqueze2/webrtc/ instead.
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.
Whiteboard: [screensharing-uplift]
You need to log in before you can comment on or make changes to this bug.