Open SetTrend opened 3 years ago
I found a workaround now (although I'm not sure why this works):
If I create a new BitmapFrame
from the FormatConvertedBitmap
, I seem to be able to freeze that new frame, even though it has been created by the same thread the FormatConvertedBitmap
has been created with:
internal static Task<BitmapSource> GetImageAsync()
{
return Task.Run<BitmapSource>(() =>
{
BitmapImage bi = new BitmapImage();
bi.BeginInit();
bi.UriSource = new Uri(@"test.jpg");
bi.DecodePixelWidth = 16;
bi.EndInit();
FormatConvertedBitmap fcb = new FormatConvertedBitmap(bi, PixelFormats.Indexed2, new BitmapPalette(bi, 4), 1);
// Required for the UI thread to be able to use the bitmap.
BitmapSource bf = BitmapFrame.Create(fcb);
bf.Freeze();
return bf;
});
}
Did anyone have the time to investigate on this issue?
The warning tells you why the workaround works, the palette is a dependency property on FormatConvertedBitmap
but not on BitmapSource
. So what you cannot freeze is in fact specifically FormatConvertedBitmap
.
I guess we could make BitmapPalette
freezable.
Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? No.
Problem description:
I'm not able to freeze a color palette based
BitmapSource
image.So, it's impossible to create a color palette based
BitmapSource
image asynchronously and yield to WPF UI thread. (See this issue on StackOverflow.)Actual behavior:
BitmapSource.CanFreeze
always yieldsfalse
when the image assigned is using a color palette.Expected behavior:
BitmapSource.CanFreeze
should returntrue
, even with bitmaps using a color palette.A color palette is a
DispatcherObject
that cannot be transferred between threads, cloned or anything else. So, there is no way to workaround this situation.Minimal repro:
WPF tracing returns the following warning message: