D3DImage - 它能做啥、解决了什么问题、有哪些瓶颈、怎么最佳实践

D3dImage，.Net Framework 3.5 之后，微软提供的一个全新的ImageSource对象，可以在WPF中很好的呈现DirectX内容；在此之前，你只能将DirectX内容直接渲染在Windows窗口之上，这必然引起令人头疼的AirSpace问题，为了在这些内容上面添加我们习以为常的WPF UI 元素，你只能使用Popup来承载这些内容，完全丧失WPF UI开发的灵活性，且有经验的WPF程序员都知道一个事实：WPF Popup就是一个深坑 - 你需要手动处理各种显示隐藏问题、因为其导致的焦点问题，显示层级问题以及最令人头疼的性能问题，特别是在4K屏幕下，因为我们都知道，Popup就是一个Window，为了解决Airspace问题而使用Popup来承载UI必定需要使其AllowTransparency=True，这就引起了另外一个问题，透明窗口占用内存与其面积成正相关，在4K屏幕下，你可能将整个程序大部分的内存占用贡献给了这些Popup UI。说了这么多，好像在诉控Popup有多么的垃圾（它的确如此，如果在做大量的UI容器时）。

年轻人，如果你觉得Airspace问题真的没有办法解决了，只能用Popup这种技术手段来规避了，那么听老人一句话，不要浪费时间在Popup上了，因为你在前期投入的时间来规避种种Popup UI导致的问题以及各种你意想不到的Bug，到最后总会碰到解决不了，完全不能规避的情况，从而导致整个Popup UI替换方案完全失败的情形。

什么是AirSpace问题

这是一个很复杂的问题，涉及到整个WPF的渲染机制，简单的来说，就是对于WPF窗口的子窗口，其并不是由父窗口负责渲染的，而是由其自己负责自己的渲染，子窗口不能像其他元素一样由父元素来进行布局、渲染（这很好理解），因此，如果我们要在一个WPF窗口中承载另外一个子窗口，那么其渲染并不受父窗口控制，它会渲染在父窗口所有元素之上，这就是导致上面提到的需要用Popup UI来规避Airspace问题的原因。那么问题来了，我为什么要在一个窗口里面渲染另外一个窗口？这不科学。这的确是一个不科学的操作，因为没人会这样做，除非你需要和DirectX内容打交道，特别是对于在WPF做多媒体应用开发的程序员，WPF和DirectX内容的交互 是一个不可避免的问题（虽然我觉得用WPF做多媒体应用本身就存在问题，但这不在本篇文章讨论的范围）。不仅是DirectX内容，在WPF中承载WinForm控件也有同样的问题，为了解决这种问题，微软曾在.Net Framework 4.5的某个预览版（如果没记错的话）中提供了对应的解决方案，但是在正式版中并没有保留，很可惜。

WPF多媒体程序开发的好帮手 - D3DImage

D3DImage就是一个全新的ImageSource，你可以完全根据你对ImageSource的理解来使用它D3DImage。为什么说它是WPF多媒体程序的好帮手？正如我上面提到的，我不觉得WPF是多媒体应用开发的第一选择，多媒体应用是一种性能敏感的程序类型，先不说使用WPF你很难触碰到底层的渲染机制，进行调优；而且，你不能原生访问Direct3D接口，即使，至少对于Windows平台下，多媒体内容大多都使用Direct3D API来进行渲染、绘制（更不用说OpenGL了，其对于WPF来说几乎就是一个不可能的选项）。因此我们需要D3DImage，其为你在WPF中使用Direct3D接口和内容提供了一种可能，尽管那是一种不那么直观的方式。
说到底，我们需要解决的问题是将Direct3D原生渲染的内容，以一种WPF熟悉的，原生的方式渲染在WPF上。在D3DImage之前，你只能直接渲染在窗口上，因为窗口是Direct3D渲染设备的必须参数。而D3DImage，不要误会，它并不是可以让Direct3D不用窗口进行渲染，而是为Direct3D渲染的内容提供了一个“通道”，这个”通道”使WPF可以将ID3DDevice上的渲染表面ID3DSurface更新到其渲染线程中（这种说法并不准确，但是你可以先这样理解，至于它们是怎样”共享“表面的，我们以后再谈）。

一切看起来都是那么完美，但是…

可以想象的到，D3DImage方式并不能提供比肩原生渲染的性能，不论是CPU占用还是内存占用。特别是当你需要兼顾Windows XP的时候，那性能就更加难看了。WPF虽然说是支持硬件加速的一个框架，但是它有原生缺陷，这篇文章描述了一些深入的问题。要知道，在Windows Vista之前，即Windows Xp，只能使用D3D9接口创建D3dDevice，我们甚至不能使用D3D9Ex接口，对于D3DImage来说，这是一个很大的性能损耗，因为由D3D9接口创建的D3dSurface与WPF的D3Dimage渲染过程中存在一个很恶心的过程，WPF需要将显存中的D3DSurface内容拷贝回系统内存，处理完后再拷贝回显存进行渲染，毫无疑问会导致CPU占用和内存占用上升。我们使用剪辑师来做一个实验，在关闭硬件加速的情况下，对比使用两种接口来创建渲染表面的性能表现：
在关闭硬件加速的情况下，使用剪辑师播放一个2K分辨率的视频在不同时刻的CPU占用：

可以看出存在明显的性能差别，在使用D3DEx接口创建渲染表面进行和WPF的交互操作时，并不存在上面提到的显存→系统内存拷贝问题，其直接在显存中进行拷贝，这样会降低CPU损耗。即使这样，它也不能提供比原生窗口渲染更好的性能，这在我们意料之内。

最佳实践

• 不要支持Windows XP
• 使用D3D9Ex以上接口来创建你要在D3DImage承载的Direct3D内容
• 不要在UI上使用DropShadowEffect，一点都不可以
  关于这一点，又是一个可以深究的问题，但是这里就先简单的说一下。在远程会议的开发中，我们在渲染8分屏的时候，发现使用D3DImage进行视频渲染的时候，性能表现远远低于原生窗口渲染的方式，虽然知道D3DImage性能上与原生渲染存在差距，但是也不可能相差这么远。刚开始的时候我并没有怀疑DropShadowEffect，因为我知道它会带来性能问题，因此我还故意将其应用到一个空的Grid上，而不是直接应用到D3DImage上，而且这个Grid和Image并不是父子关系，在我的印象中，这样可以规避将整个D3DImage的像素数据进行DropShadowEffect的管道数据处理（DropShadowEffect本质是一个像素着色器，像素着色器是一个高性能组件，对于现代3D游戏来说，是一个必不可少的组件，但是这篇文章已经提到，WPF里的像素着色器并不完全是那么一回事），按理说，性能瓶颈并不应该出现在这里，然而，它的确是这里，原因是啥？我也不清楚，或许以后有结论之后我们再开一篇文章来谈谈。