我知道WPF更灵活，所以可以考虑做更多的计算。但是由于渲染是在GPU上完成的，对于同一个应用程序（功能上和视觉上），它不会比Winforms更快吗？哪一个具有更快的运行时性能：WPF或Winforms？
我的意思是，当你没有运行任何游戏或沉重的3d渲染时，GPU不会做很重的工作，对吧？而CPU总是很忙。
这是一个有效的假设还是WPF的GPU利用率是其管道中的一个非常小的操作？
编辑：我感兴趣的应用程序是一个三维建模和动画软件，在那里你有3d视口导航和编辑场景，场景中的对象。但我想使用WPF，因为它的现代化架构，它从头开始。
编辑2：也是为了我的目的，我将使用DirectX的手为应用程序本身，因为该软件的高端需求。对于使用低端产品的用户或没有专用GPU的电脑，这没关系，因为他们不在我的主要客户区域。就像电影和游戏的其他高端3D软件一样，需要强大的计算机才能充分受益于应用程序将是可以理解的。
如果机器具有GPU，您将在WPF中获得更好的渲染性能。
我们有一个大型的桌面应用程序，我们在WinForms中编写，现在正在移植到WPF。我们目睹了更好的渲染性能，尤其是在调整窗口大小或重新绘制控件时。我们还发现WPF“controls”比WinForm控件更轻量级。如果我记得正确，WPF控件不一定需要操作系统句柄，也不要通过WndProc注册Windows窗口消息，至少不是独立的。
对于你的情况，由于你正在构建一个3D建模应用程序，哪种假设机器上有一些3D硬件，你应该绝对使用WPF而不是WinForms。
谢谢，也是因为WPF也使用GPU，所以应用程序和WPT之间会发生争斗本身在利用该资源？ – 2010-03-26 18:30:28
没有比你在自己的3D应用上使用自己的2D菜单系统更有意思了。事实上，WPF可能会更有效地做到这一点。 :) – 2010-03-26 18:38:01
这是一个很难回答的问题。
WPF性能的一大部分是你的GPU。一个好的GPU可以让WPF表现良好。 WPF可以非常高效。如果你的要求是要有一个体面的GPU，因为它是一个3D建模程序，你可能会发现WPF性能比Windows窗体更好或更好 - 尽管这取决于你使用的是什么。
话虽如此，通常很难比较 - 主要是因为WPF允许您添加大量的视觉效果，人们往往甚至不会尝试在Windows窗体中。许多WPF应用程序“看起来”更快，即使它们由于额外的视觉线索而在某些情况下实际上速度较慢。这就是说，如果你有很多控件，WPF实际上可以超过Windows窗体一个相当数量。在Windows窗体中，每个控件都需要一个单独的窗口句柄，并接收它自己的消息集。通过大量的控制，这实际上可以大幅减缓速度。
这里真正的问题应该是WPF性能。 “足够好”用于您的应用程序。如果你正在做一个3D建模应用程序，很可能WPF不会成为你的瓶颈 - 它应该没问题。
谢谢，Winforms中需要单独的窗口句柄的开销是多少？此外，由于WPF也使用GPU，应用程序和WPT本身之间会在使用该资源时发生争斗？ – 2010-03-26 18:29:59
@Joan：每个窗口句柄都必须通过消息泵接收单独的消息。如果您使用数百种控件制作屏幕，那么它在Windows窗体中确实滞后 - 尤其是在需要自定义渲染的情况下。至于“战斗” - 不是真的。请记住，Vista + W7使用图形卡进行桌面渲染 - 现代GPU非常擅长处理这个问题。我做科比。软件/ 3D建模，并专门为我们的新产品使用WPF，并且爱表演。 – 2010-03-26 18:38:51
谢谢里德。好想法。你的应用程序也可以在网上？想知道即使看截图也会很酷：O – 2010-03-26 18:47:05
对于三维建模，WPF显然比WinForms更好 - 但它仍然是一个理想的很长的路。 Winforms根本没有（直接）对3D渲染的支持，而WPF有一些。但是，对于主要针对3D渲染的程序，您可能更擅长使用更专门用于3D渲染任务的东西，例如OpenGL或Direct3D。
自己，这些都没有提供比WPF的巨大优势，但除非你在做什么是相当专业的，我不会直接使用这些。我会使用类似OpenSceneGraph或Ogre3D的东西，它可以使用其中任何一种进行渲染，但提供了更高级的界面，并且更多地用于管理渲染场景。
其中之一或两者都可能使用WPF的实际绘图 - 但我敢肯定，至少目前没有人。我不知道他们是否会 - 他们可能会 - 但我怀疑这是一个真正的优先事项，因为他们已经支持OpenGL和Direct3D。为了他们的目的，WPF没有什么优势。
谢谢，是的，这是一个相当专业的应用程序，它处理事物的方式。现在我只想支持Windows，所以会坚持使用DirectX。我知道WPF具有3D功能，但如果我没有错，我不认为它是与DirectX本身竞争的东西。但所有的用户界面等我打算使用WPF。 – 2010-03-26 18:41:19
虽然OpenGL也是可移植的，但比起DirextX更适合使用它的主要原因是只需*更好地处理。 – 2010-03-26 19:59:11
由于WPF实际上使用了DirectX，并且使用XAML来指定DirectX对象，WPF是迄今为止最简单的解决方案。
Example coding a camera in xaml：
<PerspectiveCamera x:Key="Camera"
Position="0, 0, 4"
LookDirection="0, 0, -4"
UpDirection="0, 1, 0"
FieldOfView="30"/>
谢谢，你的意思是我可以使用XAML访问整个DirectX SDK？我正在计划使用SlimDX来处理3D内容。 – 2010-03-26 18:42:35
谢谢，这是有道理的。 – 2010-03-26 19:11:41
警告：虽然我发现WPF 3D的东西很棒，但是没有什么好的方法可以将3D内容渲染到位图上，所以如果您需要导出3D场景，我会选择SlimDX的3D部分。有关更多信息，请参阅http://stackoverflow.com/questions/2179042/rendertargetbitmap-and-viewport3d-quality-issues。 – Grokys 2010-07-13 20:15:19
对于你所描述的情景应用程序，我希望WPF大幅跑赢上一个全功能的GPU的3D工作的WinForms。
应用程序类型之间的区别不仅仅在于渲染3D矢量管线。 WPF的内部体系结构与WinForms完全不同，专门用于克服从Windows GDI和WinForms应用程序多年前的经验中学到的警告。 （WinForms是围绕Windows GDI和用户模型的相对薄包装，最初创建于20世纪80年代后期，Windows用户控制模型在过去的25年中有所发展，但核心架构模式在很大程度上没有改变。）
例如，WPF总是将UI渲染与应用程序逻辑分开。当WPF窗口去绘制东西时，实际的渲染发生在后台线程上。刷新的视觉效果会在视频回扫期间翻转显示，因此您不会在屏幕上看到部分视频或“撕裂”的文物。
WinForms没有这个功能。如果您在WinForms应用程序中渲染DirectX或OpenGL表面，则必须执行翻转视频页面的工作，并确保它在恰当的时间发生，以避免屏幕撕裂工件。
Wpf的默认控件是GPU感知的，可以通过发光和透明度以及所有GPU加速进行自定义样式。 WinForms控件不会从GPU功能中获益，因为WinForms（Windows用户控件）用于呈现的唯一内容是2D比特式和矩形填充。发光，透明度，动画都可以用WinForms，但你必须做全部这项工作才能实现它们。
在WPF中，UI的柔和性主要是为了让WPF为你做的设计和样式。在WinForms中，你必须自己推像素。
三是在Windows XP上至少有一个小小的，但讨厌WPF的东西。这是在Vista中解决的，因此它会使用嵌入式Windows版本的用户（没有超过XP的RTM）。在制作高对比度动画时，伪影会失去垂直同步，甚至像播放高对比度MPEG文件一样。 – 2010-04-03 10:33:56
如果您必须支持WinXP或更早版本，我不会推荐使用WPF。仅仅因为框架在技术上可以执行并不意味着它会运行良好。 ;> – dthorpe 2011-11-08 23:47:16
那时候，没有Windows Vista Embedded，只有Windows XP Embedded :) Windows 7 Embedded在几年后才出现... – 2011-11-09 14:09:04
这取决于应用程序。 – SLaks 2010-03-26 18:12:30
抱歉应该添加更多细节。 – 2010-03-26 18:13:24
我不是专家，但我相信确切的硬件（和相应的驱动程序）也可能会对性能产生重大影响。 – 2010-03-26 18:15:07