Eto: Unterstützung für ein OpenGL-Rendering-Steuerelement.

War nicht speziell geplant, aber einfach genug zu machen. Es sieht so aus, als ob OpenTK vom MIT lizenziert ist, also würde es gut zu Eto.Forms passen.

Es könnte jedoch einige Komplikationen geben, da Sie Ihre App mit unterschiedlichen Referenzen basierend auf der Zielplattform kompilieren müssten, es sei denn, Eto.Forms hätte eine Art Wrapper um OpenTK, was ich nicht unbedingt tun möchte.

Ich habe beobachtet, dass Sie separate Plattform-DLLs für Windows, Gtk und Mac haben, könnte dies nicht der Ort sein, an dem der plattformspezifische Code platziert wird.
Um OpenTK zu verwenden, müssen Sie eine gemeinsame plattformunabhängige OpenTK.dll und eine plattformspezifische referenzieren, deren Code der bestehenden Eto.Platform.*.dll hinzugefügt werden könnte, da diese höchstwahrscheinlich bereits die erforderlichen Referenzen enthalten.

Ich habe daran gearbeitet, einen Fork von OpenTK zu modifizieren und zu entfernen, der unter https://github.com/hultqvist/opentk zu finden ist
Aber seien Sie gewarnt, dass fork einige größere Änderungen aufweist, die es mit dem ursprünglichen Opentk-Projekt (hauptsächlich mit Spaltenvektoren) inkompatibel machen.

Trotzdem hat sich der Teil, über den ich spreche, in dieser Hinsicht nicht geändert, insbesondere die Projekte OpenTK.GLControl und OpenTK.GLWidget für Windows bzw. Gtk, ich denke, ein ähnliches könnte für Mac erstellt werden, aber derzeit ist die einzige Implementierung vom Original OpenTK-Spielfensterklasse.

Das wäre in der Tat ein Weg, dies zu tun.

Ich habe mir das ein wenig angesehen - Es ist bedauerlich, dass MonoMac ein benutzerdefiniertes OpenTK verwendet, das in MonoMac.dll integriert ist. Wir müssen möglicherweise einen Wrapper um die gesamte API erstellen, was bedauerlich wäre

Hier wurden Fortschritte bei einem OpenGL-Steuerelement für eto erzielt:

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

Ist dieses OpenGL Control in einem brauchbaren Zustand?

Ich habe es nicht ausprobiert, daher bin ich mir nicht sicher, obwohl ich Screenshots davon gesehen habe, die in SharpFlame funktionieren. @bchavez , haben Sie weitere Informationen zum Zustand Ihres OpenGL-Steuerelements?

• Eto.Gl - Die _Eto Control_, aber ich habe die API noch nicht wirklich formalisiert.
• Eto.Gl.Windows - Die plattformspezifische GL sollte unter Windows mit Eto.Gl unverändert funktionieren.
• Eto.Gl.Linux - Die plattformspezifische GL unter Linux muss aufgrund einiger neuer eto- Änderungen aktualisiert werden. Sollte nicht schwer zu aktualisieren sein, hatte nur nicht genug Zeit.
• Eto.Gl.Mac - Etwas schwieriges _gotcha_ Problem, das ich noch lösen muss.

Das einzige Hauptproblem auf Mac/OSX ist, dass neue GL-Kontexte, die innerhalb derselben App erstellt werden, standardmäßig nicht gemeinsam genutzt werden. Dies bedeutet, dass Sie pro Oberfläche einen isolierten GL-Ressourcenkontext erhalten. IE: Wenn Sie eine App haben, die mehrere GL-Oberflächen verwendet, müssen Sie Texturen n mal pro Oberfläche laden, was n mal so viel Texturspeicher benötigt.

Dieses Verhalten ist unter Linux und Windows unterschiedlich. Standardmäßig werden neue OpenGL-Kontexte gemeinsam genutzt (innerhalb derselben App). Wenn Sie also mehrere GL-Oberflächen (unter Linux oder Windows) in derselben App haben und Texturen laden, laden Sie Texturressourcen nur einmal und nicht n Mal pro Oberfläche.

Einige der Hacking-Versuche, die ich unternommen habe, um es auf dem Mac zum Laufen zu bringen, sind MacGLView1-7.cs :
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

Irgendwann werde ich (oder jemand anderes) das Problem auf den Punkt bringen, damit das Verhalten plattformübergreifend konsistent ist. Hatte einfach nicht genug Zeit am Geldautomaten.

Das OSX-Dokument für das Problem ist hier:

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

Zur Verdeutlichung meine ich mit "GL-Kontext" insbesondere GL-Ressourcenkontexte . (Freigegebener Objektstatus wie im obigen Link beschrieben).

Danke für die Aufklärung. Ich habe bereits versucht, es unter Windows und Linux zum Laufen zu bringen.
Windows funktioniert gut mit Wpf, aber unter Linux mit Gtk#2 will es nicht funktionieren: http://hastebin.com/okewirerem
Hier ist der Code, wenn Sie ihn sich ansehen möchten: https://github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

Ich habe herausgefunden, dass es etwas mit der Textwiedergabe zu tun hat. Wenn Sie ein anderes Steuerelement im Layout haben, das Text rendert, stürzt es sofort ab. Wenn der Text dieses Steuerelements stattdessen leer ist, stürzt es nicht ab.

Wow, das ist seltsam.

@benklett

Ich bin auf das gleiche Problem gestoßen. Wenn Sie den Fix immer noch nicht gefunden haben, müssen Sie dies als erste Zeile Ihres gtk-Programms einfügen:

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 (); ....

Dies liegt an einer verrückten Sache mit x_multithreading oder so, also muss OpenTK da reinkommen, bevor gtk initialisiert wird. Nicht unbedingt das Erste, was Sie tun müssen, aber ziemlich früh.

Vielen Dank für Ihre Hilfe, ich muss versuchen, ob das funktioniert, wenn ich zu Hause bin.

Irgendein Update zum OpenGL-Steuerelement für eto?

Sieht vielversprechend aus: https://github.com/philstopford/etoViewport.

Re. etoViewport, es könnte WPF- und GTK3-Unterstützung vertragen, aber GTK3 verwirrt mich, wie ich vorgehen soll - es ist nicht offensichtlich, wie der benötigte Cairo-Kontext (für mich) eingerichtet wird.

Keine Ahnung, wie etoViewport es macht, aber Gtk 3 hat ein GLArea-Widget für OpenGL-Rendering: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html

Irgendwelche Updates zu diesem?

@feliwir etoViewport funktioniert ab sofort für mindestens WPF, WinForms und macOS. Ich bin mir jedoch nicht sicher, wie der Status von GTK ist.

GTK funktioniert in meinen Tests unter VirtualBox/CentOS 7.x und auch VMWare/Linux Mint. Es kann einige seltsame Treiber geben, insbesondere unter VirtualBox, wo das OpenGL-Steuerelement über allen anderen Fenstern zu schweben scheint. Ich denke, dies könnte jedoch ein Fehler in VirtualBox sein, da er in VMWare nicht zu sehen ist.

GTK3 ist jedoch nicht für etoViewport implementiert.

@philstopford Ich mag die Abhängigkeit von OpenTK nicht. Pläne, sie zu entfernen / einen benutzerdefinierten Rückruf für die Kontexterstellung zuzulassen?

Es tut mir leid, dass es dir nicht gefällt, aber ich verstehe nicht warum. Patches sind willkommen, wenn der aktuelle Ansatz für Sie nicht funktioniert. Ich habe nicht wirklich vor, es selbst zu ändern: OpenTK war ein zuverlässiges Arbeitspferd. Frühere OpenGL-Bemühungen habe ich SharpGL verwendet und dann wurde dieses Projekt aufgegeben. OpenTK wird dagegen aktiv gepflegt und ist plattformübergreifend.

Verschiebt nach: https://github.com/picoe/Eto.Toolkit/issues/7

@cwensley dies kann geschlossen werden.