Background image support

[d-bingham]

Summary of the Pull Request

Initial code check-in for background image support. Handles background images themselves, and adds options to profiles.json to control the feature.

References

#833

PR Checklist

• Closes Feature request: Add support for background images #833 (Not quite complete as the opacity setting is not fully robust, see below)
• CLA signed. If not, go over here and sign the CLA
• Tests added/passed
• Requires documentation to be updated -- Adds (currently undocumented) settings to profiles.json, but profiles.json as a whole does not appear to be documented
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: Feature request: Add support for background images #833 -- aware of the discussion in Feature request: Add support for background images #833

Detailed Description of the Pull Request / Additional comments

This adds three options to the individual profile options in profile.json:

• backgroundImage: Expects a Uri which locates an image. This property is optional and defaults to null.
• backgroundImageOpacity: Expects a number, controls opacity of the background image. Optional and defaults to 1.0.
• backgroundImageStretchMode: expects one of "none", "fill", "uniform", or "uniformToFill", which controls the stretch mode used -- see documentation here. Optional and defaults to uniformToFill.

Background images are only displayed if useAcrylic is turned off.

One known issue:

backgroundImageOpacity currently only works with respect to the application's default black background and does not respect the profile's background color.

One potential issue:

There's no attempt to handle a failed image load from the Uri; I think it is reasonable to expect the underlying classes (specifically BitmapImage) to handle this gracefully. Additionally, it's unclear how such a failure should be reported to the user (beyond their requested image being displayed as a black console background instead)

[zadjii-msft]

Additionally, it's unclear how such a failure should be reported to the user

I am working on an error dialog in #622, but that's not quite ready yet, so I'm fine with this just doing whatever for now.

[zadjii-msft]

I'm a little worried about introducing ImageStretchMode to be the same as windows.ui.xaml.media.stretch. Otherwise no complaints here :)

[miniksa]

I'm concerned as to whether this should be a property of the DxRenderer itself instead of composed on during the XAML process in the control.

But given that I don't currently have the capacity to figure that out, I'm OK with accepting this in the meantime.

[DHowett-MSFT]

I'm concerned as to whether this should be a property of the DxRenderer itself instead of composed on during the XAML process in the control.

But given that I don't currently have the capacity to figure that out, I'm OK with accepting this in the meantime.

Yeah, we can stick with this. Putting it behind the DxRenderer (literally behind) frees us from thinking about image loading, format handling, blitting, invalidation, stretch, interpolation and everything else XAML gives us for ~free.

Given that list, I'm inclined to prefer the XAML solution. 😄

[d-bingham]

Given that list, I'm inclined to prefer the XAML solution. 😄

Additionally, as far as I'm aware there's no "official" implementation of the Fluent acrylic brush in Direct2D, so the XAML layer would still be required for that effect.

[DHowett-MSFT]

This will conflict heavily with #1005. This is otherwise a very well-done feature. Let's file a follow-up to support a transparent image over top of acrylic and really set those GPUs on fire

[d-bingham]

Working on cleaning up some architectural oddities created by merging this with #891. The current PR build works, but it's inelegant (and the code gets called three times on a settings file change...)

[zadjii-msft]

@d-bingham you might not need to worry about the settings reloading issue too much. I know that it's definitely called twice per settings change, because for whatever reason, we get two file change notifications.

[d-bingham]

@d-bingham you might not need to worry about the settings reloading issue too much. I know that it's definitely called twice per settings change, because for whatever reason, we get two file change notifications.

I'm more concerned about getting a background image refresh (and the resulting flicker of the background image) resulting from terminal input introduced in #891.

[d-bingham]

Modified this a bit to make more sense with regard to #891:

• Split off brush-initialization work from Add support for OSC 10 and 11 to set the default colors #891's TermControl::_BackgroundColorChanged; _BackgroundColorChanged now only, er, changes background color
• Put the brush initialization into TermControl::_InitializeBackgroundBrush
• Enhanced TermControl::_InitializeBackgroundBrush so that the acrylic and image brushes avoid redraws (image refresh for the image brush, acrylic redraw and fade for acrylic) when they are reset

[d-bingham]

Also, critically, the flicker prevention code maintains animation state of any animated image selected as a background during a settings change that does not change the image source.

[zadjii-msft]

animation state of any animated image selected as a background

Are you suggesting we can have gifs as a background? Because that would be amazing

[d-bingham]

animation state of any animated image selected as a background

Are you suggesting we can have gifs as a background? Because that would be amazing

Yeah, just set your backgroundImage to https://lh6.googleusercontent.com/-Kde1FiWiijM/TniZsFpCyqI/AAAAAAAAD7Q/2sZC2Zqx8RM/s500/Contact500_Micael_Reynaud.gif and give it a bit to load, and it works.