Enum CaptureMode 

pub enum CaptureMode {
    Cpu {
        include_cursor: bool,
    },
    Gpu,
}

Available on Windows and crate feature dxgi-capture and (crate features dxgi-capture or wasapi-capture) only.

How DxgiCaptureSource::open captures each frame — see DxgiCaptureOptions::capture_mode.

Variants

Cpu

The original behavior: AcquireNextFrame’s resource is copied into a CPU-readable staging texture, Mapped, and copied row-by-row into a plain Pixel::BGRA CPU frame. No external device required — open creates its own, internal to this element, from the chosen output’s own adapter.

include_cursor composites the mouse cursor onto every emitted frame. Off by default: the base capture path (desktop pixels only) needs no extra work, and most consumers (recording, streaming a presentation) don’t want the cursor baked in at all. Only exists on this variant — cursor compositing is CPU-side pixel blending (composite_cursor), which has nothing to run against under CaptureMode::Gpu, where the captured image never touches the CPU at all; putting the field here instead of as a separate DxgiCaptureOptions flag makes that combination unrepresentable rather than a runtime error to guard against. Also unsupported (a hard open-time error, see DxgiCaptureSourceError::CursorUnsupportedForRegion) when DxgiCaptureOptions::area is a CaptureArea::Region spanning more than one output — see that variant’s own docs on why.

Fields

include_cursor: bool

Gpu

Captures straight to a GPU-resident frame tagged Pixel::D3D11 (BGRA — desktop content has no reason to go through YUV) — no Map, no CPU pixel copy at all, just GPU-side CopyResource/ CopySubresourceRegion calls (each contributing output’s duplication resource -> this element’s own per-output “latest capture” texture, then those -> a fresh per-emission composite texture every tick, so an in-flight pushed frame’s content can’t change under whatever’s still reading it — same reasoning crate::elements::D3d11Upload documents for building a fresh texture per call rather than reusing one).

Unlike CaptureMode::Cpu, this variant carries no device of its own to inject: open always builds the device itself, from whichever adapter DxgiCaptureOptions::area actually selects (the only place that resolves “which adapter” — see resolve_area), and hands it back as open’s own return value for the caller to reuse. That’s the one ID3D11Device every other D3D11 element sharing this capture’s output should be built from (e.g. render_common::D3d11GpuContext::new(Some(device))) — for open’s own zero-copy path to mean anything, see crate::elements::D3d11Renderer’s own docs on why. Taking a caller-supplied device here instead would only reopen the exact adapter-mismatch problem this design avoids: two independently resolved “which adapter” answers that would need to be checked against each other instead of structurally being the same one.

No cursor option — see CaptureMode::Cpu’s own docs on why.

Trait Implementations

impl Clone for CaptureMode

fn clone(&self) -> CaptureMode

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for CaptureMode

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.