まとめ(TL:DR版)
最終的に私たちの目標は、Google の ANGLE プロジェクトを使用して、エアスペースやドライバーの問題なしに、WPF アプリケーションで OpenGL ES コードをネイティブに (つまり、SharpGL などではなく) 利用できるようにすることです。
バックグラウンド:
DirectX よりも OpenGL で気に入っている点の 1 つは、そのクロスプラットフォーム機能です。OS X と Linux の両方、および ES 経由の Android と iOS で優れたサポートを提供します。ただし、Windows では、これを使用するとドライバーの問題が発生するか、さらに悪いことに、多くのカードで適切に実装されていません。
Google のANGLE プロジェクト、または Most-Native-Graphics-Layer-Engine に入ります。
ANGLE は、Direct3D 実装の OpenGL ES 2.0 ラッパーです。つまり、実際の OpenGL ドライバーを必要とせずに、Windows で実行する OpenGL ES 2.0 コードを記述できます。ES 互換性テストに合格するだけでなく、実際に Chrome が WebGL を含むすべてのグラフィックス レンダリングを行う方法であるため、実績のあるテクノロジであることは間違いありません。
質問:
WPF には、WPF 内で Direct3D レンダリングをホストできる D3DImage コントロールがあり、その出力を WPF レンダリング スレッドに適切にコンポストすることで、空域の問題を解決していると考えられます。私の質問は、ANGLE は Direct3D 経由で実装され、D3DImage は Direct3D レンダリングのターゲットであるため、2 つを組み合わせて、OpenGL ES コードを記述し、Windows 上の WPF アプリケーションでホストできるようにすることは可能ですか? ?
これが私たちにとっての「聖杯」です。
しかし、ANGLE は独自のものを使用したいので、D3DImage コントロールによって作成された D3D サーフェス上でレンダリングをターゲットにするように ANGLE を取得する際に壁にぶつかり続けています。これが可能かどうかさえわかりません。これについて議論している記事や参考文献はどこにも見つかりません。
繰り返しになりますが、目標は、エアスペースの問題や OpenGL ドライバーの要件なしに、WPF アプリケーションで動作する共有のクロスプラットフォーム OpenGL (または ES) コードを取得することです。ANGLE/D3DImage を使用するという私の提案は、単なる試みです。それは私がこれまでに思いついた「手段」ですが、それは目標そのものではなく、目標への潜在的な手段にすぎません。私たちを同じ解決策に導く他のものは大歓迎です。