Problem
SCREENSHOT's own docs are explicit that a capture over serial can
take anywhere from several seconds to several minutes (see
server/README.md's transfer-time table: up to ~9 minutes at 9600
baud for a capture at the AMIP_SCREENSHOT_MAX_BYTES cap) — and even
over TCP or Amiberry's serial-to-TCP bridge, a real capture is a
noticeably long blocking call. Amipilot.screenshot() (and WireClient
generally) gives the caller zero feedback while this is happening:
the call just blocks until the full payload has arrived, with no way
to know it's 10% done vs. hung.
Confirmed hands-on during real Picasso96/uaegfx hardware-adjacent
testing on Amiberry this session: driving SCREENSHOT against a real
P96 CLUT and truecolor screen each took tens of seconds with no
visible progress at all, and it wasn't obvious from the caller's side
whether the command was still working or had stalled.
Proposed design (sketch)
WireClient._read_exact() (host/amipilot/wire.py) is the natural
hook point: it already loops accumulating bytes via _recv() (up to
4096 bytes per call) until count bytes are buffered. An optional
on_progress: Callable[[int, int], None] | None parameter
(bytes-so-far, total) invoked after each _recv() iteration would
cover every large-payload wire read generically (SCREENSHOT,
FSGET, and any future binary-payload verb), not just screenshots.- Thread that optional callback up through
WireClient.command() and
Amipilot.screenshot()/fs_get() as an optional keyword argument
(e.g. client.screenshot(window="...", on_progress=lambda done, total: ...)),
defaulting to None (today's exact behavior, zero overhead when
unused).
- Consider a small built-in helper for the common case (print a simple
X/Y bytes or percentage line to stderr) so scripts don't all have
to hand-roll the same thing, without forcing it on callers who want
their own UI.
Why now
Filed while running real hardware-adjacent P96/SCREENSHOT verification
on Amiberry (Picasso96 3.6 + uaegfx) — the lack of any progress
feedback during a long capture was a genuine, felt annoyance doing
this by hand, not a hypothetical.
Problem
SCREENSHOT's own docs are explicit that a capture over serial cantake anywhere from several seconds to several minutes (see
server/README.md's transfer-time table: up to ~9 minutes at 9600baud for a capture at the
AMIP_SCREENSHOT_MAX_BYTEScap) — and evenover TCP or Amiberry's serial-to-TCP bridge, a real capture is a
noticeably long blocking call.
Amipilot.screenshot()(andWireClientgenerally) gives the caller zero feedback while this is happening:
the call just blocks until the full payload has arrived, with no way
to know it's 10% done vs. hung.
Confirmed hands-on during real Picasso96/uaegfx hardware-adjacent
testing on Amiberry this session: driving
SCREENSHOTagainst a realP96 CLUT and truecolor screen each took tens of seconds with no
visible progress at all, and it wasn't obvious from the caller's side
whether the command was still working or had stalled.
Proposed design (sketch)
WireClient._read_exact()(host/amipilot/wire.py) is the naturalhook point: it already loops accumulating bytes via
_recv()(up to4096 bytes per call) until
countbytes are buffered. An optionalon_progress: Callable[[int, int], None] | Noneparameter(bytes-so-far, total) invoked after each
_recv()iteration wouldcover every large-payload wire read generically (
SCREENSHOT,FSGET, and any future binary-payload verb), not just screenshots.WireClient.command()andAmipilot.screenshot()/fs_get()as an optional keyword argument(e.g.
client.screenshot(window="...", on_progress=lambda done, total: ...)),defaulting to
None(today's exact behavior, zero overhead whenunused).
X/Y bytesor percentage line to stderr) so scripts don't all haveto hand-roll the same thing, without forcing it on callers who want
their own UI.
Why now
Filed while running real hardware-adjacent P96/SCREENSHOT verification
on Amiberry (Picasso96 3.6 + uaegfx) — the lack of any progress
feedback during a long capture was a genuine, felt annoyance doing
this by hand, not a hypothetical.