Closed Bug 1053264 Opened 6 years ago Closed 6 years ago
Mouse cursor flickers after activating screensharing on Windows
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
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).
Assignee: nobody → gpascutto
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?
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.
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...
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
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
Verified fixed 35.0a1 (2014-09-09) Win 7 x64
Comment on attachment 8482341 [details] [diff] [review] Patch 1. no-captureblt-on-aero Approved for Beta and Aurora
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
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.
You need to log in before you can comment on or make changes to this bug.