Eto: Prise en charge d'un contrôle de rendu OpenGL.

Ce n'était pas spécifiquement prévu, mais assez facile à faire. Il semble qu'OpenTK soit sous licence MIT, il conviendrait donc bien à Eto.Forms.

Il peut cependant y avoir des complications, car vous devrez compiler votre application avec différentes références en fonction de la plate-forme cible, à moins qu'Eto.Forms n'ait une sorte de wrapper autour d'OpenTK, ce que je n'aimerais pas nécessairement faire.

J'ai observé que vous avez des DLL de plate-forme distinctes pour Windows, Gtk et Mac, cela ne pourrait-il pas être l'emplacement pour placer le code spécifique à la plate-forme.
pour utiliser OpenTK, vous devrez référencer une OpenTK.dll indépendante de la plate-forme commune et une plate-forme spécifique dont le code pourrait être ajouté à la Eto.Platform.*.dll existante, car celles-ci contiennent probablement déjà les références nécessaires.

J'ai travaillé sur la modification et la suppression d'un fork d'OpenTK trouvé sur https://github.com/hultqvist/openk
Mais sachez que fork a quelques modifications majeures qui le rendent incompatible avec le projet Opentk d'origine (principalement en utilisant des vecteurs de colonne).

Pourtant, la partie dont je parle n'a pas changé à cet égard, en particulier les projets OpenTK.GLControl et OpenTK.GLWidget pour Windows et Gtk respectivement, je suppose qu'un projet similaire pourrait être fait pour Mac mais actuellement la seule implémentation est de l'original Classe de fenêtre de jeu OpenTK.

En effet, ce serait une façon de le faire.

J'ai regardé cela un peu - Il est regrettable que MonoMac utilise un OpenTK personnalisé intégré à MonoMac.dll. Nous devrons peut-être créer un wrapper autour de l'ensemble de l'API, ce qui serait regrettable

Des progrès ont été réalisés sur un contrôle OpenGL pour eto ici :

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

Ce contrôle OpenGL est-il dans un état utilisable ?

Je ne l'ai pas essayé, donc je ne suis pas sûr, même si j'ai vu des captures d'écran fonctionner dans SharpFlame.. @bchavez , avez-vous plus d'informations sur l'état de votre contrôle OpenGL ?

• Eto.Gl - Le _Eto Control_, mais je n'ai pas encore vraiment formalisé l'API.
• Eto.Gl.Windows - Le GL spécifique à la plate-forme devrait fonctionner tel quel sur Windows en utilisant Eto.Gl .
• Eto.Gl.Linux - La GL spécifique à la plate-forme sous Linux doit être mise à jour en raison de nouveaux changements eto . Cela ne devrait pas être difficile à mettre à jour, je n'ai tout simplement pas eu assez de temps.
• Eto.Gl.Mac - Problème de _gotcha_ assez difficile que je dois encore résoudre.

Le seul problème majeur sur Mac/OSX est que, par défaut, les nouveaux contextes GL créés dans la même application ne sont pas partagés en ressources. Cela signifie que vous obtenez un contexte de ressource GL isolé par surface. IE : Si vous avez une application qui utilise plusieurs surfaces GL, vous devrez charger les textures n fois par surface, en prenant n fois la quantité de mémoire de texture.

Ce comportement est différent sous Linux et Windows, par défaut, les nouveaux contextes OpenGL sont partagés en ressources (au sein de la même application). Ainsi, si vous avez plusieurs surfaces GL (sous Linux ou Windows) dans la même application et chargez des textures, vous ne chargez les ressources de texture qu'une seule fois et non n fois par surface.

Certaines des tentatives de piratage que j'ai faites pour le faire fonctionner sur Mac sont MacGLView1-7.cs :
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

Finalement, moi (ou quelqu'un d'autre) vais résoudre le problème afin que le comportement soit cohérent sur plusieurs plates-formes. Je n'ai tout simplement pas eu assez de temps au guichet automatique.

Le doc OSX pour le problème est ici:

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

Pour clarifier, par « contexte GL », j'entends, en particulier, les contextes de ressources GL . (État de l'objet partagé comme décrit dans le lien ci-dessus).

Merci pour la clarification. J'ai déjà essayé de le faire fonctionner sous Windows et Linux.
Windows fonctionne bien avec Wpf, mais sur Linux avec Gtk#2 cela ne veut pas fonctionner : http://hastebin.com/okewirerem
Voici le code si vous voulez y jeter un œil : https://github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

J'ai découvert que cela avait quelque chose à voir avec le rendu du texte. Si vous avez un autre contrôle sur la mise en page, qui rend le texte, il se bloque instantanément. Si le texte de ce contrôle est à la place vide, il ne plante pas.

Waouh, c'est bizarre.

@benklett

J'ai rencontré le même problème. Si vous n'avez toujours pas trouvé le correctif, vous devez le mettre en première ligne de votre programme 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 (); ....

C'est à cause de quelque chose de farfelu avec x_multithreading ou quelque chose du genre, donc OpenTK doit y entrer avant que gtk ne s'initialise. Pas strictement la première chose que vous devez faire, mais assez tôt.

Merci beaucoup pour votre aide, il faudra que j'essaye si cela fonctionne quand je rentre à la maison.

Une mise à jour sur le contrôle OpenGL pour eto ?

Cela semble prometteur : https://github.com/philstopford/etoViewport.

Ré. etoViewport, cela pourrait faire avec le support WPF et GTK3, mais GTK3 me laisse perplexe quant à la façon de procéder - il n'est pas évident de savoir comment configurer le contexte du Caire dont j'ai besoin (pour moi).

Ne sais pas comment etoViewport le fait, mais Gtk 3 a un widget GLArea pour le rendu OpenGL : https://developer.gnome.org/gtk3/unstable/GtkGLArea.html

Des mises à jour sur celui-ci?

@feliwir etoViewport fonctionne dès maintenant pour au moins WPF, WinForms et macOS. Je ne suis pas sûr du statut de GTK cependant.

GTK fonctionne dans mes tests sous VirtualBox/CentOS 7.x et aussi VMWare/Linux Mint. Il peut y avoir une certaine bizarrerie du pilote, en particulier sous VirtualBox, où le contrôle OpenGL semble flotter au-dessus de toutes les autres fenêtres. Je pense que cela pourrait être un bogue dans VirtualBox, car il n'est pas vu dans VMWare.

GTK3 n'est cependant pas implémenté pour etoViewport.

@philstopford Je n'aime pas la dépendance à OpenTK, aucun projet de la supprimer/autoriser un rappel personnalisé pour la création de contexte ?

Je suis désolé que ça ne te plaise pas, mais je ne vois pas pourquoi. Les correctifs sont les bienvenus, si l'approche actuelle ne fonctionne pas pour vous. Je n'ai pas vraiment l'intention de le changer moi-même : OpenTK a été un bourreau de travail fiable. Au début des efforts OpenGL, j'ai utilisé SharpGL, puis ce projet a été abandonné. En revanche, OpenTK est activement maintenu et multiplateforme.

Déplacé vers : https://github.com/picoe/Eto.Toolkit/issues/7

@cwensley cela peut être fermé.