WPF Slow Tilemap渲染性能

我一直在努力將基於XNA/WinForms的現有tilemap編輯器遷移到WPF。我對WPF比較陌生，但大多數概念都不太難理解。我有一個Viewbox嵌入到ScrollViewer中，使用（Viewbox）派生的OnRender方法提供的DrawingContext中的DrawImage方法繪製地圖。問題是，當屏幕上出現相當大量的圖塊時（我的機器上> 1000），我無法實現與XNA/WinForm版本相同的性能。我已經實現了縮放和平移，但是當我縮小太多或者在屏幕上顯示大量圖塊時平移時，會出現嚴重滯後，從而導致用戶體驗崩潰。我已經採取了幾種明顯的優化措施（凍結源位圖，剔除無法看到的切片，將位圖縮放模式設置爲LowQuality，提供Cache緩存提示），但似乎無法解決問題。問題顯然在於WPF使用DrawingContext處理繪製紋理四邊形的方式。WPF Slow Tilemap渲染性能

我已經提供了所有必要的代碼示例應用程序來重現問題：SampleGridDrawingExample

按住鼠標中鍵並移動鼠標進行平移。隨着窗口大小的增加，它變得越來越明顯（顯然是因爲更多的圖塊被渲染）。

WPF中是否有比DrawingContext更快的方法來繪製大量具有合理性能的紋理四邊形？使用XNA/WinForms我可以在合理的滯後時間內在多個圖層中繪製〜50000個圖塊，而在WPF中，使用我當前的方法超過1000會導致明顯的滯後（> 10000會使應用程序爬行）。

來源

2012-05-29 batchprogram

似乎只有WPF，目前無法獲得任何接近XNA性能的地方。然而，在對XNA集成的Nick Gravelyns post進行了審視之後，我決定使用那裏列出的方法，因爲性能對於我正在開發的應用程序是可以接受的。在對樣本和隨後的壓力測試進行了一些修改之後，我設法使其足夠穩定以用於生產代碼。我強烈建議任何對XNA-> WPF整合感興趣的人來看看這篇文章。

來源

2012-05-31 20:20:45 batchprogram

我已經下載了你的樣品，它對我來說沒問題，沒有大的性能滯後。但是，如果我監視自己的表現，無論您在何時移動鼠標時執行的任何計算，似乎都會遇到某種瓶頸。請參閱附件的屏幕截圖，其中詳細介紹了移動鼠標（左半部分）並移動鼠標（右半部分）時的CPU使用情況。

CPU usage

我認爲渲染是不是會減慢速度，但在你的事件處理程序的其他代碼。爲了確定，我設置了RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;，它在我的機器上運行方式完全相同（好CPU，中等GPU）。我也檢查了這個Memleak問題，但關於這一點，它看起來沒問題 - 在我的64位窗口上，內存使用量永遠不會超過64Megs，垃圾收集可以有效地釋放資源。

你提到你以前的解決方案。您的解決方案的哪部分基於XNA？ XNA依靠硬件加速（WPF默認情況下也是如此），而WinForms則純粹是CPU加速的。誰運行你的舊魔法，你的CPU或你的GPU？

來源

2012-05-29 06:38:53

鼠標移動過程中的計算僅僅是計算鼠標增量並基於它滾動地圖。我認爲這不會是問題（但是顯然，當你移動鼠標時，它會頻繁計算，所以我理解CPU的跳躍）。舊的編輯器僅使用XNA將加載的位圖轉換爲Texture2D，並用於渲染（利用SpriteBatch）。繪製地圖的循環與樣本中的相同。所以GPU本質上是處理它，但是在計算可見區域進行剔除和對縮放/平移輸入作出反應時，會涉及到一些CPU。 – batchprogram

假設WPF在我的示例中使用了硬件加速，我知道在它和我的舊編輯器之間渲染的唯一區別在於，我的舊編輯器有一個與應用程序Idle事件關聯的循環，該事件重繪地圖的速度爲60赫茲。 – batchprogram

WPF確實使用硬件加速，但效率非常低 - 它讓所有的繪製調用都過多。其3D渲染功能意味着增強用戶界面，而不是重型渲染（例如繪製數以萬計的單個元素）。有可能你的代碼可以被優化，但肯定遠不如XNA給你的性能水平。

更好的選擇是在WPF中構建編輯器，但將渲染器保留在XNA中並將其放置在編輯器中。

來源

2012-05-30 20:27:27 Asik

WPF Slow Tilemap渲染性能

回答

相關問題