Luxar Viewer API Documentation - v2026.9.22
    Preparing search index...
    • The height the capture renders at, and the DPR it renders with.

      Dimensions are aligned DOWN to even numbers by the caller — H.264/H.265 with yuv420p need even width and height, and encoders pad internally to their own macroblock size, so nothing here has to.

      videoResolution === 0 is the panel's "Native" option, documented in its tooltip as "current canvas size" — so capture at the size the canvas actually has (display size × native DPR) rather than silently forcing 1080. Forcing it downscaled every Retina/4K capture and, because it changed the capture-to-CSS pixel ratio, rescaled the composited overlays with it.

      The display size comes from post-processing, NOT from renderer.getSize(): the renderer is handed the SSAA-multiplied size, so under SSAA it reports display × multiplier and asking to render THAT squares the multiplier (2× on a 3024×1700 canvas asked for a 12096×6800 target). saveRecordingState re-applies the multiplier itself, so the frames on disk still carry SSAA — which is what the real-time path's canvas backbuffer includes too. captureDPR, not the display's native DPR: "Native" here means "the resolution this capture renders at", which by default is what is on screen. Raise Capture DPR in the panel for a bigger export.

      Parameters

      Returns { captureDPR: number; targetH: number }