win-capture: Improve fullscreen window detection
Description
This small change allows windows that extend slightly beyond the defined viewport to be properly detected as fullscreen ones.
While, in general, one should not assume that bottom > top and right > left, win-capture is tailored to Windows, where this assumption always holds true. Therefore, simply swapping == with >= when comparing rect.right with mi.rcMonitor.right and rect.bottom with mi.rcMonitor.bottom should suffice.
Motivation and Context
While it may sound crazy, some apps on Windows use a dirty hack of extending their windows slightly beyond the monitor's declared resolution, usually by 1px, to preserve "true" windowed fullscreen and circumvent some issues related to the exclusive fullscreen mode presented by the graphics library being used, Windows itself, or both. As an example, see: https://github.com/glfw/glfw/issues/527#issuecomment-143183771.
At the moment, these windows are not recognized by OBS Game Capture because they fail the strict comparison rules defined here: https://github.com/obsproject/obs-studio/blob/48b1298fafb941f70edfa3b17bd2441e9124c3c9/plugins/win-capture/game-capture.c#L1221-L1228
And this is quite annoying because, from the user's perspective, these windows are clearly in the fullscreen mode.
Additionally, Windows itself doesn't resort to such strict comparison rules, as evidenced by the fact that the taskbar disappears, as it always does for fullscreen windows, even when a window stretches slightly beyond the defined viewport. So, if anything, this should be considered a parity feature.
How Has This Been Tested?
There isn't much to test, so I just ran the freshly built OBS on Windows in a VM to check if it works. Thankfully, a two-symbol change didn't break the project :D
The change is very localized, shouldn't affect other areas of the code, and doesn't introduce any breaking changes. It simply fixes a minor issue/tweaks the pre-existing functionality to better match the, ahem, nuances of Windows development.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- Tweak (non-breaking change to improve existing functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation. (I.e., none)
Please do not use merge commits, instead, rebase your PRs.
Apologies! It's been so long that I forgot what the contributing guidelines here look like, so I did the simplest thing possible - I resolved the conflict using GitHub's interface, since it was literally a one-line conflict, assuming the merge commit could be squashed away anyways :)
I've reordered the history, so the PR now consists of just one commit once again.