摘要(TL:DR版本)
最终,我们的目标是能够在 WPF 应用程序中本地使用 OpenGL ES 代码(即不是 SharpGL 等)并且没有 Airspace 或驱动程序问题,这可能使用 Google 的 ANGLE 项目。
背景:
我喜欢 OpenGL over DirectX 的一件事是它的跨平台能力。它对 OS X 和 Linux 以及通过 ES 在 Android 和 iOS 上都有出色的支持。但是,在 Windows 上,使用它会受到驱动程序问题的影响,或者更糟糕的是,很多卡根本没有正确实现它。
输入 Google 的ANGLE 项目,或“Almost-Native-Graphics-Layer-Engine”。
ANGLE 是围绕 Direct3D 实现的 OpenGL ES 2.0 包装器,这意味着您可以编写 OpenGL ES 2.0 代码以在 Windows 上运行,而无需实际的 OpenGL 驱动程序。它不仅通过了 ES 兼容性测试,而且实际上是 Chrome 进行所有图形渲染的方式,包括 WebGL,因此它绝对是一项经过验证的技术。
问题:
我们知道 WPF 有一个 D3DImage 控件,它可以让您在 WPF 中托管 Direct3D 渲染,并且它应该通过将其输出正确地堆肥到 WPF 渲染线程来消除空域问题。我的问题是由于 ANGLE 是通过 Direct3D 实现的,而 D3DImage 是 Direct3D 渲染的目标,是否可以将两者结合起来,允许我们编写 OpenGL ES 代码并将其托管在 Windows 上的 WPF 应用程序中,所有这些都没有驱动程序或空域问题?
这将是我们的“圣杯”。
但是,由于 ANGLE 想要使用它自己的,所以我一直在让 ANGLE 将其渲染定位在由 D3DImage 控件创建的 D3D 表面上。我不确定这是否可能。我什至在任何地方都找不到任何人讨论这个问题的文章或参考资料,更不用说尝试了。
再次明确一点,我们的目标是让我们共享的跨平台 OpenGL(或 ES)代码在 WPF 应用程序中工作,而不会出现空域问题或 OpenGL 驱动程序要求。我对使用 ANGLE/D3DImage 的建议就是……尝试。到目前为止,这是我想出的“手段”,但这只是实现我们目标的潜在手段,而不是目标本身。任何其他能让我们得到相同解决方案的东西都将受到欢迎。