Sluggish mouse cursor when window capturing?

[jpark37]

I'm not sensitive to this myself, but I'm hearing reports that capturing any window causes the Windows mouse cursor to lag in general. Some think hardware cursor is being disabled, but I don't know how to verify that. Should this be happening?

We plan to work around this by disabling WGC cursor capture, and using D3D11/GDI interop to DrawIconEx into our target texture, but I'm not sure if that will restore mouse performance.

[robmikh]

Yes, we force the software cursor when capture is on. There were some architectural reasons for this as well as an intention to prevent having a disconnect between where we would draw the cursor and where it might actually be on screen (as the hardware cursor). Although that's something we could reexamine if it proves problematic (no promises!).

I'm not sure drawing the cursor yourself would restore the performance, since we'd still be in software cursor mode. Is it a significant problem currently?

[jp9000]

I want to state that I am speaking solely for myself as the author of OBS -- not for jpark37 or anyone else.

I want to be as respectful as possible when I say this: when my own home-baked user32 solution is less invasive than WGC's solution at capturing the cursor, I'd say it's a significant problem enough. That's not the only problem with WGC, but one of the two primary problems with it.

But basically, let me tell you how we use WGC, and then you judge for yourself if it's a significant problem:

We don't use it unless we absolutely have no choice. In other words, we only use it as a fallback window capture method if GDI can't capture a window. The mouse lag due to hardware cursor being disabled, although relatively small, is noticeable on 60hz desktop compositing. We've been testing it with our users, and it was noted by many of them; I also noticed it. Also, the capture border, while likely well-intentioned (probably for "security" reasons), also deters our users from wanting to use WGC. GDI of course does not have that limitation (when it can capture at least, and it captures most windows even to this day).

In the end, we basically only use WGC for capturing browser windows, browser-based windows, or UWP programs which cannot be captured by GDI. For everything else, we use GDI to capture a specific window, because GDI has no border, and we can capture the cursor ourselves without causing cursor lag. GDI also has DirectX interop support which has great performance; it's about as fast as any other capture method we have right now.

So you be the judge. I had high hopes for WGC when I first heard about it, but now I just don't want to use it unless I absolutely have to. I'd rather just use GDI still. Maybe the higher-ups over there that make the decisions designed it for video conferencing without realizing the video game livestreaming case, who knows. All I know is that I don't want to use it in OBS unless we absolutely have no choice. Although internally it might have some performance benefits, the costs outweigh any of that progress that might have been made technologically, which makes me sad. It's unfortunate to see people put so much work in to this, but in the end for my users to not want to use it.

Again, I want to reiterate that I mean all this with the utmost respect. I hope you consider changing things, but I've dealt with corporate bureaucracy before so somehow I don't have high hopes.

Sorry, I had to go in to a rant about this, it's really important to me. WGC right now is a great feature that is held down by these two major issues (well, that and the fact that it's not normal C++, but that's another topic entirely). Until these two issues are solved, we will likely never opt for WGC by default if we can avoid it.

What you all decide to do with/about everything I've said here is up to you. Not sure who it was designed it for but it doesn't seem like it was for streamers.

[jpark37]

One other thing to note is that users historically haven't reported anything about window capture and hardware cursor capture in OBS not being in perfect temporal sync. I think that's much less of a concern than degraded mouse performance.

[robmikh]

So it appears that this is a significant problem for OBS 🙂

We'll take this into consideration, and I agree that the temporal sync issue was probably premature. We'll be looking at this seriously, we've started to discuss how we can address it.

[jp9000]

I apologize for getting worked up about it, and I appreciate you hearing me out, I got a little bit frustrated because although these things seem insignificant, they means a lot not just to myself but to the entire content creation industry. It's just really important that this industry has updated technology for capture that they can rely on as the operating system evolves. Especially as older technologies such as GDI become less and less feasible.

Thank you for all your hard work on this!

[robmikh]

I appreciate that, thank you. And thank you for the work you all do on OBS, otherwise I wouldn't be able to (selfishly) watch some great OOT speedruns!

Let us know if you run into more issues, we're happy to collect feedback. I'll also keep you two posted on our plans for this issue.

[JordanSjodinFaithlife]

@robmikh will disabling mouse capture with the new IsCursorEnabled restore the normal hardware cursor even during a capture?

[robmikh]

No it will not. This is an area that we're actively investigating, but for current public builds engaging the capture API will force the system into software cursor mode. We're looking to prevent software cursor mode being engaged on the physical panel going forward, but we're still working on it and seeing when we can land that work.