Menu ▾ ▴

#151 Output speed emulation paces bulk APC and DCS payloads

NextMajor
wont-fix
None
5
2026-09-22
2026-09-22
No

The byte pump gates every wire byte with no awareness of parser state, so a
base64 payload inside an APC or DCS string is paced at the emulated rate. At
2400 bps a 200 KB payload takes about 11 minutes with nothing on screen, which
reads as a hang.

Affected today: APC SyncTERM:C;S file store, the DrawPPMBlob,
DrawJXLBlob, LoadPPMBlob, LoadJXLBlob and LoadPBMBlob verbs, sixel, and
DCS font definitions.

Repro: BPS Rate 2400, host sends APC SyncTERM:C;S;t.wav;<200KB base64> ST.
The same at BPS Rate 0 completes immediately.

Two carve-outs already exist: parse_rip() runs over a whole wire chunk in
recv_bytes() ahead of the gate, and ZMODEM detection hands off to
zmodem_download(). Bulk APC and DCS payloads get neither.

A real 2400 bps modem would also have taken 11 minutes, so this may be
intended. Asking whether the RIP and ZMODEM carve-outs are meant to extend to
out-of-band payloads that display nothing while they stream.

Discussion

  • Stephen James Hurd

    • status: open --> wont-fix
     
  • Stephen James Hurd

    This is intentional. RIP and ZModem aren't so much carve-outs as things that were too hard to pace when pacing was added. It's likely they will be paced in a future release.

     

Anonymous
Anonymous

Add attachments
Cancel