T

leonarski_fandClaude Opus 5 eba0b47605 fix: pace sample camera frames to what the GUI can paint

image is a queued cross-thread signal and Qt's event queue has no high-water
mark, so this queue grew without bound independently of ZMQ: with a 50 Hz feed
and a GUI painting slower, the displayed frame fell further behind for as long
as the stream ran. Measured on a stand-in at 15 ms decode / 25 ms paint, the
displayed frame aged from 40 ms to 2010 ms over three seconds and kept going.

Two changes:

- Emit once and fan out on the GUI thread to whichever view is actually on
  screen, rather than connecting all three SampleCameraImageLabels. Two of the
  three are always hidden (tab / compact page / portrait page), so this is one
  repaint per frame instead of three.

- Cap the frames in flight and drop rather than queue past it. The cap is 2,
  not 1, so a frame can be queued while the GUI paints the other: at 1 the GUI
  idles waiting for the next decode (33.3 fps displayed), at 2 it does not
  (40.0 fps) for one extra frame of latency. Both stay bounded — 40 ms and
  62 ms respectively, flat over the run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DVqbXPoeHyqrQq5Vc8EcYP

2026-09-08 11:38:18 +02:00

.gitea

add 3.14 in the ci

2026-08-25 14:47:04 +02:00

.zed

feat: add hostname+user to gui logs

2026-07-06 16:27:08 +02:00

ci: introduce release workflow

2026-07-27 14:44:33 +02:00

docs

docs: udpate cheatsheet formatting

2026-08-04 15:41:29 +02:00