我知道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