在上一篇文章D3DImage - 它能做啥、解决了什么问题、有哪些瓶颈、怎么最佳实践最后，提到DropShadowEffect严重影响到D3DImage的渲染性能问题，导致程序在渲染8分屏（8个远端视频）的时候，出现严重的性能下降，渲染卡顿。要知道，在使用原生窗口渲染方案渲染8分屏，CPU占用和内存占用也不过25%和~200Mb，稍差一点，使用D3DImage优化后方案渲染，CPU占用并没有出现多大的跳跃，大约在30%左右。即使是添加了DropShadowEffect的情况下，CPU占用和内存占用好像都没有多大变化；既然在CPU和内存占用都没有多大变化的情况下，WPF渲染卡顿，那肯定（可能吧）是“帧生成”时间过长的锅。
这是一篇2011年的文章，原地址在 A Critical Deep Dive into the WPF Rendering System，个人认为到现在都可以给WPF程序开发人员作为一个参考，里面详细讲述了 WPF 这个号称从底层支持硬件加速的 UI 框架为什么有时候看起来并不是那么回事的原因。以下是正文。
刚开始我并不认为我会发表这篇文章。在被一些我高度重视的人说服后，我决定要发表这篇文章。那些深入投入微软UX平台的程序员应该更加深入了解这个平台内部是怎么工作的，当他们撞到一睹石墙的时候，他们可以清晰了解到问题所在并且更加准确地沟通他们希望平台做出怎样的改变。
如果这几个月你有关注我的Twitter，你也许会发现我一直在吐槽WPF（Silverlight也一样）的性能。为什么我会这样做？毕竟这些年我花费了大量的时间为这个平台布道、写库、社区帮助和指导等等。准确来讲，我个人全身投入到这个平台里面，我希望这个平台越来越好。
当在开发沉浸式的、消费者导向的UX的时候，性能是你第一位的特性。性能是你添加其他特性的前提和基础。有多少次因为UI太卡你需要缩小UI的规模？有多少次因为这个技术做不到所以你需要丢弃“开创性的UX模型”？有多少次你告诉客户他们需要一个2.4GHz的四核CPU才能获得全部的体验？我一直以来都被客户问，为什么在PC上拥有4倍于iPad的性能的情况下，WPF程序却做不到像iPad应用那般流畅？