Drag any corner of the floating webcam preview to resize it (120-480px per
side, kept inside the HUD viewport). The chosen size is saved and restored
the next time the HUD opens.
Fixes#1103
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"Select area or window" in the source menu opens a picker over every
display. Hovering highlights the window under the cursor, or the whole
screen over the desktop, and a click picks it. Dragging draws an area,
and moving or resizing any pick turns it into an area. Record, Enter or
a double-click starts recording, Select only picks, Escape cancels.
The window-list helper gains a --z-order mode that lists windows front
to back with their owner process, so the picker hits the frontmost
window and skips Recordly's own. A picked window or screen becomes the
same source the lists offer. An area becomes an area:<displayId> source
that the capture helper crops like a window that never moves, cursor
telemetry normalizes to, and a dashed outline marks while recording.
The main process validates every pick: a window must be one the picker
offered. Picker windows stay hidden until they have painted, so opening
the picker does not flash the app background.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lightning exports failed on Linux with:
Lightning (Beta) export failed.
Reason: Cannot read properties of undefined (reading '_resourceType')
The crash is a PixiJS 8.14 WebGPU bug, not app code. On Linux Chromium
`navigator.gpu` exists, so WebGPU initialization succeeds, but Pixi sizes
its bind group from a WebGL probe (MAX_TEXTURE_IMAGE_UNITS = 32) that
exceeds the WebGPU per-stage sampler limit (maxSamplersPerShaderStage =
16). BindGroupSystem._createBindGroup then throws on the first render,
killing the export at 0 frames. Because it fails mid-render rather than
during init, the existing backend fallback ladder never engages.
`getDefaultLightningRenderBackend()` in backendPolicy.ts already
returned "webgl" and was covered by a test, but it was never called
from production code. Instead modernVideoExporter hardcoded
`preferredRenderBackend: undefined`, which also discarded the caller's
own preference (so the `?smokeRenderBackend=webgpu` override was
silently dropped). `undefined` resolved to a WebGPU-first backend order.
- modernVideoExporter: honor the caller's preferredRenderBackend and
fall back to getDefaultLightningRenderBackend().
- modernFrameRenderer: make the unspecified case WebGL-first, matching
the legacy frameRenderer. WebGPU stays available via an explicit
preference, so the smoke-export override still works.
- Add a regression test that stubs navigator.gpu and asserts the
default resolves to webgl.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Lightning exports failed on Linux with "Cannot read properties of undefined
(reading '_resourceType')". The export renderer preferred WebGPU whenever
navigator.gpu existed, but the preview renderer always prefers WebGL, so
exports ran on a backend that never worked on this machine. PixiJS then read
a missing filter resource in BindGroupSystem._createBindGroup and threw.
Breeze was separately unreachable on Linux: its Annex B encoder probe only
tried prefer-hardware, while electron/gpuSwitches.ts disables
VaapiVideoDecoder and VaapiVideoEncoder on Linux, so the probe rejected the
software encoder that WebCodecs had already reported as supported.
- Default the export renderer to WebGL-first to match VideoPlayback.tsx;
keep WebGPU available when explicitly requested.
- Probe Breeze with prefer-hardware and fall back to prefer-software, and
configure the encoder with whichever config passed.
webadderall