你已经看到，我们在CheckBox中指定了Style属性，并引用前面的StaticResource标记。 WPF与Win32 【IT168 技术文档】
GDI是当今应用程序的主流图形库，GDI图形系统已经形成 了很多年。它提供了2D图形和文本功能，以及受限的图像处理功能。虽然在一些图形卡上支持部分GDI的加速，但是与当今主流的Direct3D加速相比还 是很弱小。GDI+开始出现是在2001年，它引入了2D图形的反走样，浮点数坐标，渐变以及单个象素的Alpha支持，还支持多种图像格式。但是， GDI+没有任何的加速功能（全部是用软件实现）。
当前版本的WPF中，对一些Win32功能还没有很好的支持，比如WMF/EMF文件，单个象素宽度的线条等等。对于这些需求还需要使用GDI/GDI+来实现。
在Windows Vista中，GDI和GDI+仍然支持，它们与WPF并行存在，但是基本上没有任何功能性的改进。对GDI和GDI+的改进主要集中在安全性和客户相关 问题上。WPF的所有提交都不依赖于GDI和GDI+，而是Direct3D。并且所有的Primitive都是通过Direct3D的本地接口实现的。 还记得我前面随笔中提到过的Milcore吗？它就是和Direct3D交互的非托管代码组件。由于WPF的大部分代码都是以托管代码的形式存在的，所以 WPF中有很多托管、非托管的交互。当然，在一些图形卡不支持WPF所需要的功能时，WPF也提供了稍微低效的软件实现，以此来支持在某些PC上运行 WPF应用程序。
在Windows Vista中，Direct3D的关键改进就是引入了新的显示驱动模型。VDDM驱动模型虚拟化了显卡上的资源（主要是显示内存），提供了一个调度程序， 因此多个基于Direct3D的应用程序可以共享显卡（比如WPF应用程序和基于WPF的Windows Vista桌面窗口管理）。VDDM的健壮性、稳定性也得到了提高，大量的驱动操作从内核（Kernel）模式移动到了用户（User）模式，这样提高了 安全性，也简化了显示驱动的开发过程。
在Windows Vista中存在两个版本的Direct3D：Direct3D 9和Direct3D 10。WPF依赖于Direct3D 9，这样能更广泛的解决兼容性问题。另外一个非常重要的原因就是为Vista的服务器版本提高方便，因为服务器版本的Vista对显卡和Direct3D 基本上没有任何的要求。同时WPF也支持Direct3D 10。Direct3D 10依赖与VDDM，只能在Windows Vista上使用。由于Windows XP没有VDDM，虽然Microsoft做了很大的努力来改善XP中Direct3D 9相关驱动，提高内容的显示质量，但是由于XP中没有对显卡资源的虚拟化，强制所有的应用程序都用软件提交。
WPF对某些多媒体的功能支持还需要依赖老的技术，比如DirectShow。当我们进行音频视频的捕捉或者其它任务时，只能直接用DirectShow实现，然后再用HwndHost嵌入到WPF内容当中。
利用类似的技术，我们可以在WPF应用程序中显示自定义格式的内容。通过提供自定义的DirectShow CODEC，然后用Media元素实现和WPF内容毫无限制的集成。
另外，WPF对XPS等文档的打印输出也得到了极大的改善。XPS文档本身的规范也极大的提高了其打印的质量，XPS文档的规范可以参考MSDN的资料。 除了打印，Vista操作系统中对远程的改进也部分依赖于WPF，比如有远程协助、远程桌面和终端服务等等。它们的实现过程是通过发送一系列的“远程”命 名到客户端，客户根据自己PC的性能和命名进行显示，这样显示的质量能得到极大的提高。
在WPF中，对Direct3D进行各种封装。当然，如果你本身对Direct3D/OpenGL很熟悉，也可以直接在WPF中使用。封装后的 Direct3D更容易使用。并且在Web应用程序（XBAP）也可以使用Direct3D。在WPF中使用的Direct3D，没有直接用非托管代码控 制所拥有的灵活性，也不能直接对硬件进行底层控制。
WPF中所有的提交都是矢量形式的，我们可以对图像或窗口进行任意级的放缩，而图像的质量不会有任何的损耗。
WPF的逻辑树和视觉树 【IT168 技术文档】
这部分的内容来自于即将出版的新书《WPF Unleashed》的第三章样章。关于什么是逻辑树，我们先看下面的一个伪XAML代码的例子：
视觉树基本上是逻辑树的一种扩展。逻辑树的每个结点都被分解为它们的核心视觉组件。逻辑树的结点对我们而言基本是一个黑盒。而视觉树不同，它暴露了视觉的 实现细节。下面是Visual Tree结构就表示了上面四行XAML代码的视觉树结构：
并不是所有的逻辑树结点都可以扩展为视觉树结点。只有从System.Windows.Media.Visual和 System.Windows.Media.Visual3D继承的元素才能被视觉树包含。其他的元素不能包含是因为它们本身没有自己的提交 （Rendering）行为。
在Windows Vista SDK Tools当中的XamlPad提供查看Visual Tree的功能。需要注意的是XamlPad目前只能查看以Page为根元素，并且去掉了SizeToContent属性的XAML文档。如下图所示：
注意图中工具栏特别标记的地方。我们可以看到Visual Tree确实比较复杂，其中还包含有很多的不可见元素，比如ContentPresenter。Visual Tree虽然复杂，但是在一般情况下，我们不需要过多地关注它。我们在从根本上改变控件的风格、外观时，需要注意Visual Tree的使用，因为在这种情况下我们通常会改变控件的视觉逻辑。
WPF中还提供了遍历逻辑树和视觉树的辅助类：System.Windows.LogicalTreeHelper和
System.Windows.Media.VisualTreeHelper。注意遍历的位置，逻辑树可以在类的构造函数中遍历。但是，视觉树必须在经 过至少一次的布局后才能形成。所以它不能在构造函数遍历。通常是在OnContentRendered进行，这个函数为在布局发生后被调用。
其实每个Tree结点元素本身也包含了遍历的方法。比如，Visual类包含了三个保护成员方法
VisualParent、 VisualChildrenCount、GetVisualChild。通过它们可以访问Visual的父元素和子元素。而对于 FrameworkElement，它通常定义了一个公共的Parent属性表示其逻辑父元素。特定的
FrameworkElement子类用不同的方式 暴露了它的逻辑子元素。比如部分子元素是Children Collection，有是有时Content属性，Content属性强制元素只能有一个逻辑子元素。 WPF中的命令与命令绑定 【IT168 技术文档】
说到用户输入，可能我们 更多地会联想到键盘、鼠标、手写笔，其实还用一种高级别的输入——命令（Commands），从WPF类库角度讲他们分别对于Keyboard， Mouse，Ink与ICommand。命令是一种语义级别的输入而不是设备级别的，比如“复制”与“粘贴”，但实现一个命令可以有很多中方式，比如“粘 贴”，我们可以使用CTRL-V，也可以使用主菜单或右键菜单（上下文菜单）等等。在以往的.net版本中，要在软件界面上添加一个“粘贴”按钮，是非常 麻烦的事情，你得监视剪切板中是否有可用的文本以及对应的文本框是否获得了焦点以便启用或禁用该按钮，当粘贴时你还得从剪切板中取得相应的文本并插入到文 本框的合理位置，等等。
在WPF中提供的命令机制能非常简单地实现这些任务，下面的Demo演示了如何简单到不用手动编写一行后台逻辑代码便解决上面的难题的，你可以粘贴下面的代码到XamlPad: