新しいプロジェクトを始めようとしています。いくつかの決定は私の手に負えません：WPFとOpenGLの使用はそれらのいくつかです。
ただし、OpenGLオプションをOpenTKまたはSharpGLの2つに絞り込みました。SharpGLにはWPFコントロールがありますが、OpenTKにはWindowsフォームコントロールしかないため、Windowsフォームホストに埋め込む必要があります：-/空域の制限は気にしませんが、適切なパフォーマンスが必要です。リアルタイムアプリケーションを構築しているので。ゲームではありませんが、それでもリアルタイムです。
「純粋な」WPFコントロールでSharpGLを使用する場合と比較して、Windowsフォームホスト上でOpenTKを使用する場合、プログラムはどの程度のパフォーマンスの低下をもたらしますか？
パフォーマンスに関しては、私は実際にあなたにただ一つの答えを与えることができます：あなた自身でベンチマークをしてください！しかし、あなたが精巧な推測を求めているので：
SharpGlは、Windowsフォームホストコントロールを「中間」ブリッティングターゲットとして除外するため、間接ステップが少なくて済みます。しかし、これを一粒の塩と一緒に取ってください。私はソースを見たり、自分でテストしたりしていません。
しかし実際には、パフォーマンスは非常に似ているはずです。結局のところ、計算量の多い操作はおそらくレンダリング自体であり、これはOpenGLによって実行されます。完成した結果をブリットするのにかかる時間はほんのわずかです。ですから、あなたがどのように決定したとしても、これらのオプションのどれもあなたのパフォーマンスを実際に損なうことはないことを願っています。
議論のために：レンダリング自体（OpenGL部分）が16ミリ秒かかると仮定すると、理論上のパフォーマンスは約60FPSになります。フレームワークAは1ミリ秒のオーバーヘッドを追加し、フレームワークBは4ミリ秒のオーバーヘッドを追加します。オーバーヘッドにこのかなり大きな違いがある場合でも、フレームワークaは約58 FPSでレンダリングされ、フレームワークBは約50FPSでレンダリングされます。したがって、どちらの場合も、アプリケーションは引き続き使用可能である必要があります。
しかし、私を困惑させるのは、あなたがこの側面についてどれだけ疑問に思っているかということです。結局、あなたはOpenGLで作業をしているので、事態が悪化した場合に備えて、基盤となる実装を単純に切り替えるのはそれほど面倒なことではないでしょうか。インターフェースは私にはそれほど違いはないようです。
OpenTKを使用するか、SharpGLを使用する方が快適な場合は、Winformsモードで使用し、WPFアプリケーションに埋め込みます。
その理由は、OpenGLドライバーは、すべてのwinformsコントロールに付属しているウィンドウハンドルの操作方法を知っているためです。WPFアプリケーションには、メインウィンドウの1つであるウィンドウハンドルが1つだけあります。使ってみてもいいのですが、問題が多すぎると思います。
画面に直接レンダリングしたくない場合で、PixelBufferObjectまたはRenderBufferObjectの使用を検討している場合は、WPFモードのSharpGLで問題ない可能性があります（結果のバッファーを画像（おそらくWritableBitmapなどを使用）、または同じことを自分で行うことができます。