我正在开发一个允许用户使用 ItemsControl 操作多个图像的应用程序。我开始运行一些测试,发现该应用程序在显示一些大图像时出现问题 - 即。它不适用于高分辨率 (21600x10800)、来自 20MB 的图像 http://earthobservatory.nasa.gov/Features/BlueMarble/BlueMarble_monthlies.php ,尽管它显示了来自 http://zebu.uoregon.edu/hudf/hudf.jpg 的 6200x6200、60MB 哈勃望远镜图像就好了。
最初的解决方案只是指定了一个 Image 控件,其 Source 属性指向磁盘上的一个文件(通过绑定(bind))。使用 Blue Marble 文件 - 图像将不会显示。现在这可能只是一个隐藏在时髦的 MVVM + XAML 实现深处某个地方的错误——Snoop 显示的可视树如下所示:
窗口/边框/AdornerDecorator/ContentPresenter/Grid/Canvas/UserControl/Border/ContentPresenter/Grid/Grid/Grid/Grid/Border/Grid/ContentPresenter/UserControl/UserControl/Border/ContentPresenter/Grid/Grid/Grid/Grid/Viewbox/ContainerVisual/UserControl/Border/ContentPresenter/Grid/Grid/ItemsControl/Border/ItemsPresenter/Canvas/ContentPresenter/Grid/Grid/ContentPresenter/Image...
现在调试这个! WPF 可以像那样疯狂......
无论如何,事实证明,如果我创建一个简单的 WPF 应用程序 - 图像加载就很好。我试图找出根本原因,但我不想花数周时间。我认为正确的做法可能是使用转换器来缩小图像 - 这就是我所做的:
ImagePath = @"F:\Astronomical\world.200402.3x21600x10800.jpg";
TargetWidth = 2800;
TargetHeight = 1866;
和
<Image>
<Image.Source>
<MultiBinding Converter="{StaticResource imageResizingConverter}">
<MultiBinding.Bindings>
<Binding Path="ImagePath"/>
<Binding RelativeSource="{RelativeSource Self}" />
<Binding Path="TargetWidth"/>
<Binding Path="TargetHeight"/>
</MultiBinding.Bindings>
</MultiBinding>
</Image.Source>
</Image>
和
public class ImageResizingConverter : MarkupExtension, IMultiValueConverter
{
public Image TargetImage { get; set; }
public string SourcePath { get; set; }
public int DecodeWidth { get; set; }
public int DecodeHeight { get; set; }
public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
{
this.SourcePath = values[0].ToString();
this.TargetImage = (Image)values[1];
this.DecodeWidth = (int)values[2];
this.DecodeHeight = (int)values[3];
return DecodeImage();
}
private BitmapImage DecodeImage()
{
BitmapImage bi = new BitmapImage();
bi.BeginInit();
bi.DecodePixelWidth = (int)DecodeWidth;
bi.DecodePixelHeight = (int)DecodeHeight;
bi.UriSource = new Uri(SourcePath);
bi.EndInit();
return bi;
}
public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture)
{
throw new Exception("The method or operation is not implemented.");
}
public override object ProvideValue(IServiceProvider serviceProvider)
{
return this;
}
}
现在这工作正常,除了一个“小”问题。当您仅在 Image.Source 中指定文件路径时 - 与使用 BitmapImage.DecodePixelWidth 相比,应用程序实际上使用更少的内存并且运行速度更快。如果您有多个指向同一图像的图像控件,则加上 Image.Source - 它们只使用与只加载一个图像一样多的内存。使用 BitmapImage.DecodePixelWidth 解决方案 - 每个额外的 Image 控件使用更多内存,并且每个控件使用的内存都比仅指定 Image.Source 时多。也许 WPF 以某种方式以压缩形式缓存这些图像,而如果您指定解码尺寸 - 感觉就像您在内存中获得未压缩的图像,而且它需要 6 倍的时间(也许没有它,缩放是在 GPU 上完成的?),加上感觉原始高分辨率图像也被加载并占用空间。
如果我只是缩小图像,将它保存到一个临时文件,然后使用 Image.Source 指向该文件 - 它可能会工作,但它会很慢并且需要处理临时文件的清理.如果我能检测到未正确加载的图像 - 也许我只能在需要时缩小它,但 Image.ImageFailed 永远不会被触发。也许它与视频内存有关,而这个应用程序只是将更多视频内存用于深层视觉树、不透明蒙版等。
实际问题:如果我只需要低于原始分辨率的特定分辨率,我如何才能像 Image.Source 选项一样快速加载大图像,而不使用更多内存用于额外副本和缩小图像的额外内存?另外,如果没有图像控件再使用它们,我不想将它们保留在内存中。
最佳答案
我做了一个简单的测试(一个图像),使用 DecodePixelWidth 与在 XAML 上设置源,使用 DecodePixelWidth 加载需要 28MB,而没有缩小时需要 178MB。我很确定它不会将原始图像保留在内存中。
既然你说你正在处理多个图像,我怀疑这是一个图像重用问题。默认情况下,WPF 将缓存一个 BitmapImage 对象(无论是通过代码还是在 XAML 中创建)。它查看 SourceUri 以及 DecodePixelWidth 和 DecodePixelHeight 以找到匹配项。如果您的 TargetWidth 和 TargetHeight 发生变化,则意味着 WPF 无法重新使用其图像缓存;如果您在没有任何额外选项的情况下设置源,这将不是问题。
关于c# - 在 WPF 中使用带有大图像的图像源,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2504359/