Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long-lived BitmapImages with ms-appx:// source get unloaded or corrupted #10080

Open
mqudsi opened this issue Oct 17, 2024 · 0 comments
Open
Labels
bug Something isn't working needs-triage Issue needs to be triaged by the area owners

Comments

@mqudsi
Copy link

mqudsi commented Oct 17, 2024

Describe the bug

I have a WinUI/WinAppSDK app that remains open & running for days or weeks at a time and have observed a regression in BitmapImage as of 1.6.240829007 that affects BitmapImage instances loaded from a ms-appx:// source (only tested with PNG).

These BitmapImages are created once and used repeatedly in the app (via the backing ImageSource property of Image instances). Everything starts off fine but after some time the images in the UI that are loaded from the ms-appx://-backed BitmapImage end up blanking out (as if the BitmapImages were null, even though the BitmapImage is not null, the Image in question is not null, and the Image.Source corrects to the correct BitmapImage instance).

Re-setting the Source property of the Image to the same BitmapImage value does not help, neither does calling PropertyChanged for the Image property of the bound object.

In this app, the same UI field is populated either with a dynamically created BitmapImage or with one of several fallback ms-appx://-backed readonly static BitmapImages loaded once at app startup and never written to or modified thereafter. The images that were created from a dynamically created BitmapImage continue to display correctly but only images loaded from a BitmapImage backed by a (png) ms-appx:// url end up being corrupted/broken (though they continue to appear to be loaded just fine when inspecting the state of the software in the debugger, instead of visually).

This behavior was observed after upgrading from WindowsAppSDK version 1.5.240627000; I don't believe the previous version exhibited this behavior even after the app was left running for weeks.

For context, the image is a property of a UI element that is bound to a list view's item template, so there is a huge list that has been virtualized and the "profile picture" is either loaded from a per-item value or falls back to a static generic placeholder. So the same code applies to thousands of entries in the list view but after days it is only those that point to the statically loaded ms-appx://-mapped BitmapImage that end up no longer appearing in the UI while those that were dynamically constructed and not backed by an ms-appx:// url continue to work. There is no code that operates specifically on entries that don't have a custom per-entry image, the same code that touches one touches the other. The readonly static BitmapImage loaded from the ms-appx:// is not even referenced anywhere in the code besides being mapped via a Xaml source converter in the same ternary expression as the one that uses the dynamically constructed BitmapImage instead.

Steps to reproduce the bug

  1. Add a PNG to the Assets folder
  2. Add an Image to your XAML form, possibly as a member of a ListView with 1000s of entries so that some of them are virtualized with multiple of them sharing the same BitmapImage source.
  3. At startup, create a BitmapImage with its uri set to ms-appx://path/to/image.png
  4. Bind the Image's Source property to the BitmapImage for many of the ListView images, some at the top of the list, some in the middle, and some at the end.
  5. Leave the app running for an extended period of time, switch virtual desktops, minimize the app, run it in the background, leave it unfocused for a day+ at a time, etc.

Expected behavior

Regardless of whether the BitmapImage was sourced from an ms-appx:// URL or from a dynamically created BitmapImage, it should remain resident in the UI if it hasn't been unset, modified, or disposed.

Screenshots

No response

NuGet package version

None

Windows version

No response

Additional context

No response

@mqudsi mqudsi added the bug Something isn't working label Oct 17, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage Issue needs to be triaged by the area owners
Projects
None yet
Development

No branches or pull requests

1 participant