Trait D3d11FrameRenderer 

pub trait D3d11FrameRenderer: Send {
    // Required methods
    fn device(&self) -> ID3D11Device;
    unsafe fn submit_bgra_texture(
        &self,
        texture: ID3D11Texture2D,
        array_index: u32,
        width: u32,
        height: u32,
    ) -> Result<(), SubmitError>;
    unsafe fn submit_nv12_texture(
        &self,
        texture: ID3D11Texture2D,
        array_index: u32,
        width: u32,
        height: u32,
    ) -> Result<(), SubmitError>;
    fn resize(&self, width: u32, height: u32) -> Result<(), SubmitError>;
}

Available on Windows and crate feature d3d11 and (crate features d3d11 or d3d12 or wasapi-renderer) only.

What D3d11Renderer needs from an actual DX11 window/rendering implementation — the D3D11 sibling of crate::elements::D3d12FrameRenderer, deliberately not an impl of that trait (it’s documented as inherently D3D12-only). Unlike the D3D12 trait, neither submit method here takes a fence or a keep_alive — see crate::elements::D3d11Renderer’s own docs on why a single shared ID3D11Device needs no explicit GPU-side synchronization at all, and this doc comment’s own note below on why lifetime-keeping is unnecessary too. Both paths here are zero-copy (no CPU-upload method the way D3d12FrameRenderer::submit_yuv420p is one): everything in this crate’s D3D11 stack already produces GPU-resident Pixel::D3D11 textures (see crate::elements::D3d11Upload/ crate::elements::DxgiCaptureSource’s GPU capture mode/ crate::elements::D3d11Decoder), so there’s no CPU-side pixel data left to upload by the time a frame reaches here.

No keep_alive parameter (unlike D3d12FrameRenderer::submit_nv12_texture): D3D11’s own COM+driver contract already defers actually freeing a resource’s GPU memory until the GPU has finished any outstanding work that reads it, regardless of when the app-level reference count hits zero — this is precisely the abstraction D3D12 (deliberately) doesn’t provide, which is why that side needs the caller to keep the source frame alive by hand via an explicit fence. Here, once D3d11Renderer::submit_d3d11_frame’s local texture clone (and whatever Arc<UnboundObjectPoolRef<..>> produced it) drops, the runtime — not this crate — is what keeps the actual texture memory valid for as long as the GPU still needs it.

Required Methods

fn device(&self) -> ID3D11Device

The ID3D11Device this implementation actually renders/submits with. D3d11Renderer reads this once at construction to guard every submit against a texture from a different device — same reasoning as D3d12Renderer’s own device-mismatch guard.

unsafe fn submit_bgra_texture( &self, texture: ID3D11Texture2D, array_index: u32, width: u32, height: u32, ) -> Result<(), SubmitError>

texture is a plain packed-BGRA surface — from crate::elements::DxgiCaptureSource’s GPU capture mode or crate::elements::D3d11Upload fed a BGRA source. array_index is always 0 for these producers (neither ever builds an array texture) — see submit_nv12_texture’s own docs on why it’s a parameter here at all.

Safety

texture must be a valid ID3D11Texture2D on the same ID3D11Device this renderer was created with, DXGI_FORMAT_B8G8R8A8_UNORM, with array_index < its ArraySize.

unsafe fn submit_nv12_texture( &self, texture: ID3D11Texture2D, array_index: u32, width: u32, height: u32, ) -> Result<(), SubmitError>

texture is an NV12 surface — from crate::elements::D3d11Decoder or crate::elements::D3d11Upload fed an NV12 source. array_index is which slice of texture this frame actually is: libavcodec’s own D3D11VA hwaccel decode pools frames as slices of one shared array texture (unlike D3d11Upload, which always builds a fresh non-array, single-slice texture per frame — array_index is always 0 there) — see d3d11va_texture’s own docs.

Safety

texture must be a valid ID3D11Texture2D on the same ID3D11Device this renderer was created with, DXGI_FORMAT_NV12, with array_index < its ArraySize.

fn resize(&self, width: u32, height: u32) -> Result<(), SubmitError>

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors