Skip to content

2.2.2

Latest

Choose a tag to compare

@github-actions github-actions released this 01 Nov 15:46

PixelFlux 2.2.2

A release that publishes a change as it lands on every capture path that waits for one (XShm and DRI3 on the X server's damage report, the Wayland compositor on a client's commit) rather than at the frame timer's next tick, captures through the DRI3 1.0 servers of NVIDIA's X driver before 595, holds NvFBC to its frame rate on a still screen, and brings NVENC's 10-bit, 4:4:4, and constant-rate paths to older drivers, with fixes to the portal host capture, the still-screen cleanup under a constant rate, VA-API, and screenshots.

Capture & Pacing

  • A change is published as it lands : the X11 XShm and DRI3 captures and the Wayland compositor pace in windows, one frame a period at most, the first change in a period taking its frame at once, as NvFBC's driver pushes them. A change no longer waits for the next timer tick, or half a period after the last frame. A spinner's change to frame on XShm and DRI3 fell from about 11 ms to about 4 at the 95th percentile. On the compositor, a client committing on its own clock went from 11 / 18 ms (median / 95th percentile) to 2.6 / 4.3, one drawing on frame callbacks from 28 / 36 to 13 / 21, and the redraw that answers input from 17 / 17 to 8.5 / 15. The rate never rises above the cadence, which input could push past before
  • DRI3 1.0 : a server that takes buffers without a layout (the NVIDIA X driver before 595, which reports DRI3 1.0 for want of modifier support) is captured through DRI3 with a linear pool, where the capture used to decline it for XShm. On a GTX 1080 Ti at 1080p a frame is delivered in 2.6 ms against XShm's 3.6, at the same quality
  • DRI3 in streaming mode published each change at the tick, 9-14 ms after it landed; it now takes it as XShm does
  • NvFBC on a still screen holds its frame rate: a grab waited a whole frame for damage that would not come and the encode followed it, 55 frames a second at 60 on a Tesla K80 and 47 on an L4 in Turbo; it now waits only until the frame's deadline
  • NvFBC after a resize : a capture whose region the root shrank under is rebuilt inside the new root rather than stopping

Encoding & Pipeline

  • NVENC on older drivers : HEVC and AV1 at 10 bits on drivers below API 12.2; the QP delta map handed where drivers below API 12.0 read it; constant rate in a single pass where the driver refuses the quarter-resolution first pass; a 4:4:4 request the GPU's engine lacks handed to the software encoder; a session kept across a resize where the device coded its 4:4:4 or 10-bit request down
  • VA-API : the AV1 render size signalled where the driver pads the frame, so a client crops it to the configured size; Intel's full HEVC encoder given Skylake's block sizes and a slice quantizer every coding unit can reach, which ended corrupt streams at high quality
  • The still-screen cleanup under a constant rate : its rate-control frames are kept to the cleanup's rate, so a sender holding the stream to its rate no longer drops the sweep's bands; a frame the sender withheld no longer starts the cleanup over; and where a sweep's least band still runs past its budget, the rest of the picture is refreshed whole rather than crawling on in ever smaller bands

Resilience & Fixes

  • Portal host capture : input notifications sent one at a time in the order they came; absolute pointer motion sent in the stream's logical size to every backend, and pointer motion and a finger's scroll placed in each path's space on a scaled output; the portal's cursor metadata taken at the size Mutter offers it; a stream's format kept when only the preferred size changes; a quiet host's frame kept across the capture restarts of a size change; and the stale-size screenshot error a tick never delivered dropped
  • Screenshots : a lossless Wayland screenshot is compressed off the compositor thread, with an admission limit per display and overall; a GLES screenshot is read back on the GPU's time into a persistently mapped buffer, and its pixels handed over in a kept buffer, copied once. A 4K screenshot's tick took 14.8 ms and takes 9.5

Build & CI

  • Releases are cut the way the other selkies-project repositories cut theirs: from the Actions tab with the tag, or by pushing it
  • Dependency updates for the crates and the GitHub Actions