Cursor may become invisible when recording some fullscreen games using WGC

[Esvandiary]

There seems to be a software-dependent issue with WGC window capture where the user's cursor may disappear when recording certain fullscreen games.
For clarity: this isn't the cursor appearing or not appearing in the recording, this is the actual system cursor becoming invisible within a fullscreen window while WGC is recording it. The same issue does not appear using other recording methods (e.g. DXGI desktop duplication, BitBlt), and enabling/disabling the WGC option to show the cursor in recordings does not seem to change the behaviour.

We've been getting user reports about this for a while (and mercifully one of our QA team can reproduce it), and the OBS project has had reports about the same on their forums for a few years including examples of both window and screen capture suffering from this issue. However, this obviously isn't an across-the-board problem, and myself and several of my colleagues can't reproduce it at all.

So far we've had reports for Minecraft Java Edition and Geometry Dash, which I believe both use OpenGL. We've also had reports on both NVIDIA and AMD GPUs (although we've only seen AMD via user reports so slight grain of salt).

I've built the WPF ScreenCapture sample and sent it to my colleague, and he was able to reproduce the issue. He's on Windows 11 Home 22H2 (22621.3007) with an NVIDIA GPU, but we also have user reports from other Windows 11 versions on builds 22621 and 22631.
Repro steps:

• Start Minecraft Java Edition (he was using 1.20.1)
• Press F11 to fullscreen the game
• Start the ScreenCapture sample
• Click Use Picker and select the Minecraft window
• Click OK
• Note that the system cursor is now invisible whenever it is over the Minecraft window
• Click Stop Recording
• Note that the system cursor is now visible again

I'm not sure if this is a known issue, but it'd be really great to have one of:

• A way to stop this from happening with no user involvement (and a pony too, please!)
• A way to stop this from happening with user involvement
• A way to detect this specific issue is happening (so we can fall back to a different window capture strategy)
  • We can try to get the cursor info to detect it being suppressed/not visible, but this is the normal behaviour in some games so it's a bit awkward

I can ask my colleague for more information or to test other scenarios if it'll help. Thanks!

[robmikh]

Hmmm, interesting. It likely has something to do with the software cursor, as that is forced on with WGC. The good news is that in an upcoming release we've finally removed the transition to the software cursor while capturing. But I'll see what I can find for existing builds.

[Esvandiary]

Thanks very much! I'll read up on software vs hardware cursor differences and see if that can give me any leads on finding anything in common between people who can reproduce the issue.

Even if the issue can't be worked around on existing builds (as I imagine may be quite likely), finding a differentiator would be very beneficial, since it gives us more fine-grained options than the bludgeon of "fullscreen game + hidden cursor = fall back to DXGI/BitBlt."

I'll also try to narrow down whether OpenGL actually is a common factor here or if that's just coincidence based on the games that have been reported.

[robmikh]

Of course! And thanks for digging up more information. If you want to force the software cursor without WGC, you can turn on cursor trails. I think there's also a magnifier API to do so, but I can't remember off the top of my head.

Additionally it would be good to know what builds of Windows this behavior is seen on. Seems like I needed to read your original post closer. Oops!

[Esvandiary]

Yeah, we've definitely seen it on Win11 22621 and 22631; I'll dig through some of the other user reports and see if I can find any other cases (e.g. I imagine a yes/no for Win10 would be useful! Might struggle for that though as we disable WGC by default on 10 since our users mostly aren't fans of the yellow border)

[Esvandiary]

Quick update for you @robmikh : we haven't managed to get any definite confirmations for Win10 or other Win11 builds, but we've made the following observations:

• Interestingly, in all cases the issue appears to only manifest when a single graphics adapter is active in the system
  • caveat: I suspect all the games I've tested personally were only actually willing to go into true exclusive fullscreen mode if a single adapter was active, even if the display in question was connected to the same adapter as the application was using for rendering in multi-adapter scenarios
  • I struggled to test the case where the compositing adapter was also the same, because it seems many games don't respect the Windows graphics "set this application to power saving" setting and just use the dGPU anyway; not sure if there's any hack possible to force compositing to run on a specific adapter to test this
• In terms of 3D APIs:
  • OpenGL applications are definitely affected while running in exclusive fullscreen
  • DirectX applications don't seem to be affected
  • Vulkan applications are likely not affected (see later for rationale):
    • Dota 2 (with the "Vulkan support" DLC installed, running with the -vulkan launch option) is affected
    • Doom Eternal is unaffected
• Enabling cursor trails to force the software cursor without recording gives mixed results
  • Minecraft Java Edition (OpenGL) does not exhibit the same behaviour as with WGC; the cursor has no trails, but is visible
    • to me this suggests a WGC-specific issue beyond just use of the software cursor
  • Dota 2 (Vulkan) does exhibit the same behaviour as with WGC; the cursor is invisible while exclusive fullscreen is active
    • so this is likely a separate, wider issue related to the software cursor with some Vulkan apps
  • Doom Eternal (Vulkan) continues to behave normally
• The WGC-specific behaviour with OpenGL has now been reproduced on NVIDIA, Intel and AMD GPUs, so unlikely to be a vendor driver problem

All of my testing above was tested on a mix of Win11 22631.3447 and 22631.3527

[robmikh]

Thanks for the extra info, this will definitely help!

[Esvandiary]

One more quick update: we're getting some scattered reports of this issue with League of Legends too, which AFAIK is a D3D game, not OpenGL... so the GL specificity may be coincidence rather than an actual symptom.

[Esvandiary]

Clarification on the above: it looks like there are two separate situations that can cause this, only one of which I'd say is actually a bug.

• OpenGL games: as above, this still seems to be a bug
  • It seems like there's some correlation between single adapter and/or single monitor being relevant for the issue happening, but not enough data to say that for sure yet
  • I have Win11 24H2 on a new laptop, and it does not happen with WGC capturing a fullscreen Minecraft window there, where based on our current understanding I would have expected it to. Not sure if that hardware cursor change made it into 24H2, but maybe that's fixed it if so... Will ask colleagues to check with other devices once 24H2 is available for them.
• Other games (e.g. League of Legends): only happens if the user has turned on "Disable fullscreen optimizations" either for the application in question or globally
  • As I understand it, turning on that option re-enables "real" traditional exclusive fullscreen mode, which means that the DWM/compositor has no opportunity to draw a software cursor and therefore if the hardware cursor is disabled, there will be no cursor unless the game draws its own
  • This isn't a bug as such, just a limitation of WGC with the old-style exclusive fullscreen (which fortunately we can detect)
  • This doesn't seem to be fixed in 24H2 (I tested with Counter-Strike 2 on my laptop), which I'd expect it to have been if the hardware cursor was no longer disabled when using WGC... so maybe it's a different change?

[Esvandiary]

Hi @robmikh, just an update on this with 24H2 info.
So far it seems like we have mixed results with the OpenGL-specific issue on 24H2:

• I have a Thinkpad T14s (Snapdragon) laptop with 24H2 which does not exhibit the disappearing cursor issue with Minecraft
• My colleague has an x86_64 desktop with an NVIDIA GPU which does still exhibit the disappearing cursor issue with Minecraft

Did the change to support HW cursor while recording with WGC make it into 24H2 in the end, or did it get shelved?

I mainly ask because this issue has become rather more urgent for us, as it seems that DXGI output duplication also no longer works properly on 24H2 with GL fullscreen apps in some cases (from our limited testing it's always multi-monitor setups with issues, so potentially when MPO is not enabled for all connected monitors based on this post?). Historically DXGI capture has been our reliable fallback when WGC was unsuitable for some reason, so now we're left with BitBlt-based capture as our only viable option for GL games on 24H2, which is a fairly dire state of affairs.

If you'd be open to discussing this issue and/or the DXGI duplication one, I'm alot on Discord (I'm in the DX12 Discord server and have been talking in #dx9-dx11-developers). Alternatively if you can point me to a better place to report these issues that works too - I realise the duplication issue is rather off-topic for this repo.

edit: after some further discussion in the DX12 Discord, it looks like the GL issue was also some form of exclusive fullscreen mode being activated resulting in the DWM not having a chance to draw the software cursor. Changing the NVIDIA drivers to send GL/Vulkan rendering through a DXGI swapchain fixes this issue (and works around the DXGI duplication issue) since now the DXGI fullscreen optimizations take effect and the DWM can draw the cursor.

I'd still be interested to know how the HW cursor work landed (or didn't) in 24H2 though 😄

[robmikh]

Sorry for the delay! I need to look at this more closely, sorry you've waited so long.

To answer your question about the new cursor support in 24H2, we found some bugs last minute and had to turn the feature off. We've been chipping away at those and hope to turn it back on sometime next year. This is a feature I've personally been pushing for for awhile!

[Esvandiary]

@robmikh Thanks very much for the update! That's useful info and helps us enumerate our options.

It seems like even the GL case isn't really a bug in WGC, strictly speaking, because contrary to what I thought it is going into some sort of "true" fullscreen mode and so the DWM doesn't get a chance to draw the software cursor. So, the hardware cursor change should probably fix all cases I know of when it's ready. Apologies for the confusion over that.

Not sure what to do about fullscreen GL apps in 24H2 for now though; before we could just consistently fall back to DXGI DD capture for GL apps, but now with DD not working in multi-monitor scenarios unless GL present is layered on top of a DXGI swapchain (which can cause compatibility issues with some games) I don't think we really have any good options. I guess we'll investigate enabling hook-based capture for GL apps and try to measure the performance impact of BitBlt desktop window capture in case hooking isn't reliable. (e: scratch that, BitBlt'ing the desktop window DC doesn't work either for real fullscreen GL of course 😂)