Eto: OpenGLレンダリングコントロールのサポート。

特別に計画されたわけではありませんが、簡単に実行できます。 OpenTKはMITライセンスを取得しているようですので、Eto.Formsにうまく適合します。

ただし、Eto.FormsにOpenTKのようなラッパーがない限り、ターゲットプラットフォームに基づいて異なる参照を使用してアプリをコンパイルする必要があるため、いくつかの問題が発生する可能性があります。

Windows、Gtk、Mac用に別々のプラットフォームDLLがあることを確認しましたが、プラットフォーム固有のコードを配置する場所ではありませんでした。
OpenTKを使用するには、1つの共通プラットフォームに依存しないOpenTK.dllと、既存のEto.Platform。*。dllにコードを追加できる特定のプラットフォームを参照する必要があります。これらにはすでに必要な参照が含まれている可能性が高いためです。

私はhttps://github.com/hultqvist/opentkにあるOpenTKのフォークを変更して削除する作業を行ってきました
ただし、フォークには、元のOpentkプロジェクト（主に列ベクトルを使用）と互換性がないようにするいくつかの大きな変更があることに注意してください。

それでも私が話している部分はその点で変わっていません、特にWindowsとGtk用のプロジェクトOpenTK.GLControlとOpenTK.GLWidgetはそれぞれMac用に作ることができると思いますが、現在のところ唯一の実装はオリジナルからのものですOpenTKゲームウィンドウクラス。

確かに、それはそれを行う方法になります。

これを少し見てみました-MonoMacがMonoMac.dllに組み込まれているカスタムOpenTKを使用しているのは残念です。API全体のラッパーを作成する必要があるかもしれません。これは残念なことです。

ここでetoのOpenGLコントロールが進歩しました：

https://github.com/bchavez/SharpFlame/tree/eto/source

このOpenGLコントロールは使用可能な状態ですか？

試したことがないのでわかりませんが、SharpFlameでスクリーンショットが機能しているのを見ました。

• Eto.Gl -_ Eto Control_ですが、APIはまだ正式に作成していません。
• Eto.Gl.Windows -プラットフォーム固有のGLは、 Eto.Glを使用するWindowsでそのまま機能するはずです。
• Eto.Gl.Linux -Linux上のプラットフォーム固有のGLは、いくつかの新しいetoの変更のために更新する必要があります。 更新するのは難しいことではありませんが、十分な時間がありませんでした。
• Eto.Gl.Mac -まだ解決する必要のあるやや難しい_gotcha_問題。

Mac / OSXの1つの大きな問題は、デフォルトで、同じアプリ内で作成された新しいGLコンテキストがリソース共有されないことです。 これは、サーフェスごとに分離されたGLリソースコンテキストを取得することを意味します。 IE：複数のGLサーフェスを使用するアプリがある場合は、テクスチャをサーフェスごとにn回ロードする必要があり、テクスチャメモリの量のn倍を消費します。

この動作はLinuxとWindowsで異なり、デフォルトでは、新しいOpenGLコンテキストは（同じアプリ内で）リソース共有されます。 したがって、同じアプリ内に複数のGLサーフェス（LinuxまたはWindows）があり、テクスチャをロードする場合、テクスチャリソースをロードするのは、サーフェスごとにn回ではなく1回だけです。

Macで動作させるために私が行ったハッキン​​グの試みのいくつかはMacGLView1-7.csです：
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

最終的に、私（または他の誰か）が問題を突き止めて、動作がクロスプラットフォームで一貫するようにします。 ちょうど十分な時間atmがありませんでした。

この問題のOSXドキュメントは次のとおりです。

https://developer.apple.com/library/mac/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_contexts/opengl_contexts.html

明確にするために、「GLコンテキスト」とは、具体的には、GLリソースコンテキストを意味します。 （上記のリンクで説明されている共有オブジェクトの状態）。

明確化していただきありがとうございます。 私はすでにそれをWindowsとLinuxで動作させようとしました。
WindowsはWpfで正常に動作していますが、Gtk＃2を使用するLinuxでは動作したくありません： http ：
ご覧になりたい場合のコードは次のとおりです： //github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

私はそれがテキストレンダリングと関係があることを知りました。 テキストをレンダリングするレイアウトに他のコントロールがある場合、それは即座にクラッシュします。 そのコントロールのテキストが代わりに空の場合、クラッシュしません。

うわー、それは奇妙です。

@benklett

私は同じ問題に遭遇しました。 それでも修正に遭遇しない場合は、これをgtkプログラムの最初の行として配置する必要があります。

C# [STAThread] public static void Main(string[] args) { //this MUST be the first line in the program or any text + the opengl window will cause it to segfault OpenTK.Toolkit.Init (); ....

これは、x_multithreadingなどの奇妙なことが原因であるため、gtkが初期化される前にOpenTKがそこに入る必要があります。 厳密には最初にやらなければならないことではありませんが、かなり早い段階です。

私が家に帰ったときにそれがうまくいくかどうか私が試みなければならないあなたの助けを本当にありがとう。

etoのOpenGLコントロールの更新はありますか？

有望に見えます： //github.com/philstopford/etoViewport。

再。 etoViewport、それはWPFとGTK3のサポートで行うことができますが、GTK3はどのように進めるかについて私を困惑させます-必要なCairoコンテキストを設定する方法は明らかではありません（私には）。

etoViewportがどのようにそれを行っているかはわかりませんが、Gtk 3にはOpenGLレンダリング用のGLAreaウィジェットがあります： https ：//developer.gnome.org/gtk3/unstable/GtkGLArea.html

これに関する更新はありますか？

@feliwir etoViewportは現在、少なくともWPF、WinForms、およびmacOSで機能します。 GTKの状況はわかりませんが。

GTKは、VirtualBox / CentOS7.xおよびVMWare / LinuxMintでのテストで動作しています。 特にVirtualBoxでは、OpenGLコントロールが他のすべてのウィンドウの上に浮かんでいるように見えるため、ドライバーに奇妙な点が生じる可能性があります。 ただし、VMWareには見られないため、これはVirtualBoxのバグである可能性があると思います。

ただし、GTK3はetoViewportには実装されていません。

@philstopford OpenTKへの依存関係が気に入らないので、OpenTKを削除したり、コンテキスト作成用のカスタムコールバックを許可したりする予定はありませんか？

気に入らなくてすみませんが、理由はわかりません。 現在のアプローチがうまくいかない場合は、パッチを歓迎します。 自分で変更する予定はありません。OpenTKは信頼できる主力製品です。 以前のOpenGLの取り組みでは、SharpGLを使用していましたが、そのプロジェクトは中止されました。 対照的に、OpenTKは積極的に保守されており、マルチプラットフォームです。

移動先： https ：

@cwensleyこれは閉じることができます。