Terminal output becomes garbled after doing imgcat on large images

[anongit]

Describe the bug

When I do wezterm imgcat image.png the terminal output in all the tabs becomes unreadable, screenshots:

macos

linux

After `reset` output is still garbled.

Environment

• OS: macOS Catalina
• Version: wezterm 20210502-154244-3f7122cb
• The active keyboard layout name: ABC (English)
• GPU: Intel HD Graphics 4000

---

• OS: Debian 10
• Version: wezterm 20210507-075424-2add312c
• The active keyboard layout name: us
• GPU: Intel HD Graphics 3000

To Reproduce

# the image size seems to be depended on terminal and font sizes
convert -size 20x8158 xc:white /tmp/image.png
wezterm imgcat /tmp/image.png

Configuration

Can be reproduced with the default config / no config.
Here is a reduced one that has the bug on my system with the 20x8158 image:

return {
  initial_rows = 52,
  initial_cols = 230,
  font_size = 11,
  -- easier to reproduce with HorizontalLcd
  -- but happens anyway for even larger images like:
  -- image.png: PNG image data, 6720 x 9630, 8-bit/color RGB, non-interlaced
  freetype_load_target = "HorizontalLcd",
}

[wez]

Does this also happen with the nightly build?
If so, please share any logging that appears in the debug overlay (CTRL+SHIFT+L in the nightly)

[wez]

Also: CTRL-= (IncreaseFontSize) and then CTRL-_ (DecreaseFontSize) may flush the texture atlas and help to workaround if this happens.

[anongit]

Does this also happen with the nightly build?

Yes.

There is nothing in the debug log:

08:18:32.476 INFO wezterm_mux_server_impl::local > setting up /Users/user/.local/share/wezterm/gui-sock-12053
08:18:32.648 INFO wezterm_gui::termwindow > OpenGL initialized! Intel HD Graphics 4000 OpenGL Engine 4.1 INTEL-14.7.13 is_context_loss_possible=false wezterm version: 20210615-193431-f752d0e7

Do I need to somehow increase verbosity? Btw, the output of the debug overlay is also unreadable, but copy pasting works anyway.

CTRL-= (IncreaseFontSize) and then CTRL-_ (DecreaseFontSize) may flush the texture atlas and help to workaround if this happens.

Doesn't help.

[anongit]

I had an idea to look for errors in the system logs:

2021-06-18 14:30:58.358162Z 0x7e1f8  Fault kernel: (IOAcceleratorFamily2) virtual bool IOAccelTask::freeToAllocGPUAddress(IOAccelMemoryMap *): failed to alloc GART space at segment 0. Needed 1073741824 bytes, used 1090973696, size 1879048192. vram=0
2021-06-18 14:30:58.358172Z 0x7e1f8  Fault kernel: (IOAcceleratorFamily2) IOAccelMemoryMap *IOAccelResource2::prepareBackingInTaskWithOption(IOAccelTask *, uint32_t): failed to allocate GPU virtual address for mapping <private>.

This:

Needed 1073741824 bytes, used 1090973696, size 1879048192. vram=0

Makes sense if 16k rgba texture is being requested with needed = 1073741824 = 16384 * 16384 * 4, but there is not enough memory.

 2021-06-18T14:30:56.722Z INFO  wezterm_gui::glyphcache        > DecodedImage::with_single(w: 20, h: 8193)
 2021-06-18T14:30:56.723Z INFO  wezterm_gui::glyphcache        > GlyphaCache<SrgbTexture2d>::new_gl(128, 128)
 2021-06-18T14:30:56.723Z INFO  wezterm_gui::glyphcache        > Texture #2 (dimensions: 128x128x1x1) depth: None, requested fmt: Specific(Srgb(U8U8U8U8))
 2021-06-18T14:30:56.728Z INFO  wezterm_gui::glyphcache        > DecodedImage::with_single(w: 20, h: 8193)
 2021-06-18T14:30:56.728Z INFO  wezterm_gui::glyphcache        > GlyphaCache<SrgbTexture2d>::new_gl(16384, 16384)
 2021-06-18T14:30:56.728Z INFO  wezterm_gui::glyphcache        > Texture #1 (dimensions: 16384x16384x1x1) depth: None, requested fmt: Specific(Srgb(U8U8U8U8))
 2021-06-18T14:30:58.185Z INFO  wezterm_gui::glyphcache        > DecodedImage::with_single(w: 20, h: 8193)

Debian laptop running with MESA_DEBUG=1:

Mesa: User error: GL_INVALID_VALUE in glTexImage2D(invalid width=16384 or height=16384 or depth=1)
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
... more GL_INVALID_OPERATION in glTexSubImage2D ...

On this system GL_MAX_TEXTURE_SIZE is 8192, so it's no surprise that images larger than that fail, but there should be a check to avoid accidentally doing imgcat on such files.

[wez]

Thanks for digging in! Now that I know what to look for, I can think about addressing this.

Meanwhile, I think you may be able to recover from this state by clearing the scrollback and then increasing and then decreasing the font size.

[wez]

I've pushed a couple of commits that should at least give you a mostly readable terminal in this situation.

There may be more that could be done to make this more reasonable; for example, we could potentially scale the image if it is larger than the displayable screen, however, there are complications with this around animated formats (we'd have to scale every individual frame) and dealing with subsequent resizes (eg: if you make the window bigger, should we re-scale to fit?).

[anongit]

Just tried it in nightly, works exactly as I expect. Thanks!
There is however 100% cpu usage and typing is really slow until you clear, but I suppose it belongs to a different issue.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.