我正在研究一个允许用户通过使用ItemsControl来操作多个图像的应用程序。我开始运行一些测试，发现应用程序有问题显示一些大的图像 - 即。它没有与高分辨率（21600x10800），从 http://earthobservatory.nasa.gov/Features/BlueMarble/BlueMarble_monthlies.php 20MB图像，虽然它显示从http://zebu.uoregon.edu/hudf/hudf.jpg的6200x6200,60MB哈勃望远镜图像很好。使用图像源与WPF中的大图像
原始解决方案只是指定了一个带有指向磁盘上文件（通过绑定）的Source属性的Image控件。随着蓝色大理石文件 - 图像将不会显示。现在，这可能只是一个隐藏在时髦MVVM + XAML实现深处的bug - Snoop显示的可视化树如下所示：
Window/Border/AdornerDecorator/ContentPresenter/Grid/Canvas/UserControl/Border/ContentPresenter/Grid /网格/网格/网格/边框/网格/ ContentPresenter /用户控件/用户控件/边框/ ContentPresenter /网格/网格/网格/网格/ Viewbox控件/ ContainerVisual /用户控件/边框/ ContentPresenter /网格/网格/ ItemsControl的/边框/ ItemsPresenter /画布/ 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.Source更多的内存。也许WPF以某种方式以压缩形式缓存这些图像，而如果指定了解码维度 - 感觉就像在内存中获得未压缩的图像一样，再加上花费6倍的时间（可能没有它在GPU上进行缩放），再加上感觉像原始的高分辨率图像也被加载并占用空间。
如果我只是缩放图像，将其保存到一个临时文件，然后使用Image.Source指向文件 - 它可能会工作，但它会很慢，它将需要处理临时清理文件。如果我可以检测到没有正确加载的图像 - 也许我只能根据需要缩小它，但Image.ImageFailed永远不会被触发。也许它与视频内存和这个应用程序只是使用更深的视觉树，不透明蒙版等使用它更多的事情
实际问题：如何加载大图像像Image.Source选项一样快如果我只需要它们的分辨率低于原始分辨率，那么不需要使用更多的内存用于缩小图像的额外副本和额外内存？另外，如果没有Image控件再使用它们，我不想将它们留在内存中。
我意识到21600x10800 = 233280000像素是一个相当大的图像，890MB的未压缩的RGBA数据，如果作为一个整体存储在内存中。内存不足问题通常无法通过代码很好地处理，因此如果WPF由于可用内存不足而无法加载映像，则很可能无法轻松检测到这些问题。它仍然是很好的能够找到解决方法... – 2010-03-24 17:25:37