當使用基於DirectX的API和WPF（即SlimDX，SharpDX等）時，你可以使用子窗口大小的控件嗎？

Question

在我們的WPF應用程序中，我們需要爲音頻應用程序顯示約64個實時電平表。我們在WPF上所做的測試，即使在渲染基本原語時效率仍然很高，因爲我們仍然可以將它顯示在離應用程序需要的地方很遠的地方，但這往往會讓主線程陷入沉重的困境，直到它無法響應輸入。

因此，我們必須去的東西的圖形性能更優化，例如DirectX的（通過SlimDX或SharpDX）或OpenGL/ES（通過阿特拉斯將它轉換爲DirectX的電話。）

我的問題是，如果有可能創建多個小的基於DirectX的區域，每個區域代表一個單獨的儀表，或者就此而言，甚至是正確的方法？我理解你必須至少在整個窗口運行它，而不是其中的一部分。

我在後者看到的問題是領空問題，其中您不能在同一窗口中將DirectX內容前的WPF內容，並且我們確實不希望在DirectX中重做所有控件，對於其他非米95％的我們的UI WPF非常棒！

我讀過，你可以渲染DirectX到畫筆，然後使用WPF內部，或使用WriteableBitmap類，它可以直接訪問緩衝區WPF然後在其渲染線程中使用，這兩者似乎並不受到空域問題困擾，但似乎我們會回到同一個地方，因爲WPF仍然需要進行渲染，所以它是瓶頸。

我們當然要花幾周的時間來測試所有上述應用程序，但我想知道我是否正朝着正確的方向前進，和/或是否有任何我們可以避免的注意事項通過與有經驗的人交談來避免常見的陷阱等。因此，任何意見都將被讚賞。

我希望我們甚至可以啓動一個wiki來討論這個話題，因爲它似乎是一個受歡迎的話題，雖然遍佈整個地方，很難讓新進入者獲得他們所尋求的信息。

Answer 1

使用wpf/d3d interop，您應該始終嘗試創建最小數量的interop調用。因此，您應該更喜歡在單個渲染目標中渲染所有64級計量器（也可以批量渲染原始渲染，並在最少數量的gpu調用中繪製所有內容）。

您應該嘗試使用D3DImage API，它允許您使用wpf渲染器共享您自己的D3D紋理。

Answer 2

如果WPF無法真正處理這64個移動條，那麼您可以使用一個D3DImage並使用Direct3D9直接將所有條直接渲染到它。對於您的具體情況，您不應該有任何性能問題。