Describe the bug
When an email contains a multi-MB inline image, view/html.go decodes the base64 body, holds the decoded bytes, runs them through the image protocol (kitty/sixel/iTerm2), and stages the encoded version in the LRU. For a single 20MB inline image we're holding 60+MB of byte slices in flight, on top of the cache. Heavy email threads OOM matcha on small machines.
Expected behavior
Stream the image bytes through the protocol encoder rather than buffering them whole. Cap the per-image cache entry size; spill very large images to disk.
Why it's hard
The image protocol encoders (sixel, kitty graphics) currently want the whole image. Streaming requires a chunked encoding path or a clever pre-resize step.
Describe the bug
When an email contains a multi-MB inline image,
view/html.godecodes the base64 body, holds the decoded bytes, runs them through the image protocol (kitty/sixel/iTerm2), and stages the encoded version in the LRU. For a single 20MB inline image we're holding 60+MB of byte slices in flight, on top of the cache. Heavy email threads OOM matcha on small machines.Expected behavior
Stream the image bytes through the protocol encoder rather than buffering them whole. Cap the per-image cache entry size; spill very large images to disk.
Why it's hard
The image protocol encoders (sixel, kitty graphics) currently want the whole image. Streaming requires a chunked encoding path or a clever pre-resize step.