feat(Core): use SharpCapture instead of xcap #89
Conversation
This removes the dependency on the Rust library known as xcap as I am going to do the screenshotting myself in tree. This *will* give greater flexibility to SnapX and ensure we're always up to date using the latest modern & secure API fors Screen Capture. Additionally, all the Rust code has been sent into oblivion. I have been working on this initial implementation for Linux for weeks. Turns out, Wayland is a complicated beast. What a shame it's come against me, though. Poor thing never stood a chance.
|
The Label Bot has predicted the following:
|
![codefactor-io[bot]](https://avatars.githubusercontent.com/in/25603?s=60&v=4){kind=small}
|
|
||
| public class WindowsCapture : BaseCapture | ||
| { | ||
|
|
There was a problem hiding this comment.
An opening brace should not be followed by a blank line.
|
|
||
| public class WindowsCapture : BaseCapture | ||
| { | ||
|
|
There was a problem hiding this comment.
An opening brace should not be followed by a blank line.
…no-rust # Conflicts: # SnapX.Avalonia/SnapX.Avalonia.csproj # SnapX.Core/FeatureFlags.cs # SnapX.Core/Media/Screenshot.cs # SnapX.Core/ScreenCapture/Rust/Cargo.lock # SnapX.Core/SnapX.Core.csproj # SnapX.Core/Utils/CaptureHelpers.cs # SnapX.Core/Utils/Native/Clipboard.cs
This was a bug, I forgot to add it to the switch statement.
This only works with the -PrintScreen parameter as I am about to finish work for the day. The colors on the screenshot are messed up but I suspect that's an easy fix
| { | ||
| break; | ||
| } | ||
|
|
There was a problem hiding this comment.
A closing brace should not be preceded by a blank line.
| { | ||
| DebugHelper.WriteException(new InvalidOperationException("Adapter is not initialized.")); | ||
| factory.EnumAdapters1(0, out Adapter); | ||
|
|
There was a problem hiding this comment.
A closing brace should not be preceded by a blank line.
This should get codefactor off my back
…ct Windows code This should actually fix builds on Ubuntu.
Additionally, it fixes capturing the active monitor (the monitor where the cursor is)
This should actually work this time around. Maybe.
This should be a minor performance bump for dotnet run -PrintScreen for testers with multiple monitors
Awesome, I'm excited for a demo! |
…no-rust # Conflicts: # .github/Progress.md # SnapX.Core/ScreenCapture/Rust/Cargo.lock # SnapX.Core/ScreenCapture/Rust/Cargo.toml # SnapX.Core/ScreenCapture/Rust/src/lib.rs # SnapX.Core/Utils/Native/Methods.cs # SnapX.Core/Utils/OsInfo.cs
github-actions
bot
added
the
packaging
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
I hate Swift I HATE IT SO BAD
| config.showsCursor = true | ||
| config.queueDepth = 5 | ||
|
|
||
| var filter: SCContentFilter? = nil // Initialize filter as optional |
There was a problem hiding this comment.
Initializing an optional variable with nil is redundant
| var filter: SCContentFilter? = nil // Initialize filter as optional | |
| var filter: SCContentFilter? // Initialize filter as optional |
Replaces my broken attempt. I will RETURN! No other platforms are affected.
|
Once checks pass, this PR shall be merged. I acknowledge the macOS swift sharp capture code does not compile. So, until it does. xcap is back in service for macOS. This PR will be merged as is. It’s an improvement for Windows & Linux. :) |
Powered by SharpCapture
With this PR, we call the necessary libraries via a layer known as SharpCapture. It is not a library, just an implementation of virtual methods for each supported platform (Linux, Windows, and macOS in-progress)
Preface
The purpose of this PR is to remove the dependency on Rust. Due to the way Rust compiles, it adds a bunch of build dependencies to link the resulting binary against the necessary libraries it uses. The Rust toolchain is even more GBs that dissuades potential contributors who are only interested in C#. Additionally, the auto-generated file
snapxrust.csis hilariously large piece of code I don't understand. As a nice plus, no more *.so file has to be right next to the SnapX assembly iesnapx-ui.exesnapx-gtk.Linux
For Linux, xcap used X11's facilities to screenshot on X11. On Wayland, it'd use Gnome Shell's Screenshot DBUS facilities or the FreeDesktop Screenshot Portal. SharpCapture now purely uses the FreeDesktop XDG Screenshot Portal on Wayland or X11. This can be improved later on.
Windows
For Windows, screenshotting should be slightly faster & be able to capture DirectX games that are in fullscreen & are controlling the screen. Previously, xcap used GDI+. Now, it uses Direct3d11 to screenshot.
macOS
Additionally, the minimum supported version of macOS is 12.3 now instead of 11 or 12. Thanks to dropping the outdated avf foundation screenshotting functionality and using the modern ScreenCaptureKit. If possible, I'd like to use the new ScreenshotKit that requires macOS 14+ and fallback to ScreenCaptureKit.