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>
webadderall