Terminal Background Image Support

[qwerasd205]

Adds support for background images via the background-image config.

Resolves #3645, supersedes PRs #4226 and #5233.

See docs of added config keys for usage details.

Note

Unlike what is implied by the original issue, because this is implemented in the renderer it is inherently per-surface not per-window, meaning a window with a split will have two copies of the background image.

Future work

• We should probably introduce code in the apprts that tells surfaces their position and size relative to the window, which would allow us to add a background-image-area config with options for surface and window to control that behavior (and probably default it to window). That apprt code would also allow for window-relative custom shader locations, which is also a fairly common user request, so I think it's worth it.
• Currently if you use a high res background image this is fairly inefficient, since each surface independently loads a copy of the background image. On systems with limited VRAM this could be an issue for users who use a lot of surfaces, so it may be worth making a shared image cache to avoid this problem.
• It's probably worth using compressed texture formats for images, I'll look in to doing that. (c43702c)

[qwerasd205]

Turns out using compressed image formats is a trivial change (already happens automagically on Metal and it's just a few lines different on OpenGL), so I'll add that as a commit to this PR.

[mitchellh]

We should probably introduce code in the apprts that tells surfaces their position and size relative to the window, which would allow us to add a background-image-area config with options for surface and window to control that behavior (and probably default it to window). That apprt code would also allow for window-relative custom shader locations, which is also a fairly common user request, so I think it's worth it.

Yes, but I want to do this in a slightly more thoughtful way. The core needs to be come generally layout aware to enable a number of features:

• tmux control mode
• save/restore layouts
• single background
• custom shader awareness for splits

Probably more. So we should do this in a way that knocks all those out, I think.

Currently if you use a high res background image this is fairly inefficient, since each surface independently loads a copy of the background image. On systems with limited VRAM this could be an issue for users who use a lot of surfaces, so it may be worth making a shared image cache to avoid this problem.

Yes, we should do this similar to how we do our font grid. Future PR.

[mitchellh]

I rebased and I updated the background-image docs to have a lot more details and note the VRAM issue.