WPF 作为 OpenGL 纹理

Question

我正在开发一个模拟器，它依赖于 OpenGL 来显示符号、 map 、移动项目......作为图层/纹理。

我们正在研究在模拟器中引入多点触控支持的不同选项。

WPF 是其中一种选择，因为它可以为 GUI 开发提供有趣的生产力因素。已经构建了一个原型(prototype)，但它不符合我们的性能要求。

我正在寻找一种提高性能的方法或任何可以让我们重回正轨的建议。

目前的系统是基于

使用 C++ 和 OpenGL 编写的主/托管应用程序，驱动(启动、调度、停止...) WPF 部分并提供上下文信息

支持多点触控的 WPF 应用程序，可根据主上下文和用户输入做出相应 react

用于在 Main/hosting 应用程序和 WPF 应用程序之间进行通信的 COM 组件

由特定抽象层管理的多点触控输入(处理 TUIO 或专有事件)

主机应用程序调度程序每 xx 毫秒(通常 xx < 50-60 毫秒)向 WPF 应用程序请求捕获/位图，并将此位图添加为 OpenGL 纹理 (glTexImage2D) 以呈现模拟窗口。

WPF 呈现其位图的当前方式依赖于 RenderTargetBitmap。渲染时间约为 500 毫秒，这比我们希望的速度至少慢 10 倍，并且消耗过多的 CPU(在这种情况下，WPF 使用软件管道)。

所以，我的问题是:

有没有办法在保持其所有功能(例如透明度)的同时更快地呈现 WPF 窗口的位图？我知道gdi32 API，但它似乎不支持透明度之类的东西，我不知道我们是否可以获得任何性能

当前架构看起来不是最佳选择，因为执行了两次“渲染”(WPF 应用程序本身的渲染和位图的渲染)。 WPF 是否有可能在某个虚拟内存空间中渲染一次，该虚拟内存空间可以由主/托管应用程序直接读取？

Answer 1

渲染 API

首先，您不应该混合使用 WPF 和 OpenGL，因为 WPF 是基于 DirectX 的。确保您在 DirectX 9.0+ 硬件上运行 WPF 以获得最佳性能。

渲染

每次发生一些假定的布局更改时，WPF 都会重新计算其显示的整个布局，这可能会非常昂贵。因此，请确保始终使用足以完成您的任务的最简单的容器(即，当 Canvas 足够好时不要使用 Grid)。

内存管理

为了改进内存处理，您可以使用弱事件(当不再需要处理程序时从对象中释放事件处理程序)，使用 VirtualizingStackPanels 而不是 StackPanels 来最小化 UI 元素的内存影响，并使用可卡住对象。