Eto: Soporte para un control de renderizado OpenGL.

No fue planeado específicamente, pero fue bastante fácil de hacer. Parece que OpenTK tiene licencia del MIT, por lo que encajaría bien con Eto.Forms.

Sin embargo, podría haber algunas complicaciones, ya que tendría que compilar su aplicación con diferentes referencias basadas en la plataforma de destino, a menos que Eto.Forms tuviera una especie de envoltura alrededor de OpenTK, lo que no necesariamente me gustaría hacer.

He observado que tiene DLL de plataforma separadas para Windows, Gtk y Mac, ¿no podría ser esa la ubicación para colocar el código específico de la plataforma?
Para usar OpenTK, deberá hacer referencia a un OpenTK.dll independiente de la plataforma común y a una plataforma específica cuyo código podría agregarse al archivo Eto.Platform. *. dll existente, ya que lo más probable es que ya contengan las referencias necesarias.

He estado trabajando modificando y eliminando una bifurcación de OpenTK que se encuentra en https://github.com/hultqvist/opentk
Pero tenga en cuenta que fork tiene algunas modificaciones importantes que lo hacen incompatible con el proyecto Opentk original (principalmente usando vectores de columna).

Aún así, la parte de la que estoy hablando no ha cambiado en ese sentido, específicamente los proyectos OpenTK.GLControl y OpenTK.GLWidget para Windows y Gtk respectivamente, supongo que se podría hacer uno similar para Mac pero actualmente la única implementación es del original. Clase de ventana de juego OpenTK.

De hecho, esa sería una forma de hacerlo.

Miré esto un poco. Es desafortunado que MonoMac use un OpenTK personalizado integrado en MonoMac.dll .. Es posible que tengamos que crear un contenedor alrededor de toda la API, lo cual sería desafortunado

Se ha avanzado en un control OpenGL para eto aquí:

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

¿Está este control OpenGL en un estado utilizable?

No lo he probado, así que no estoy seguro, aunque he visto capturas de pantalla funcionando en SharpFlame .. @bchavez , ¿tienes más información sobre el estado de tu control OpenGL?

• Eto.Gl - El _Eto Control_, pero todavía no he formalizado la API.
• Eto.Gl.Windows - GL específico de la plataforma debería funcionar como está en Windows usando Eto.Gl .
• Eto.Gl.Linux - GL específico de la plataforma en Linux necesita actualización debido a algunos nuevos cambios nuevos de eto . No debería ser difícil de actualizar, simplemente no he tenido suficiente tiempo.
• Eto.Gl.Mac - Problema _gotcha_ algo difícil que todavía necesito resolver.

El único problema importante en Mac / OSX es, de forma predeterminada, que los nuevos contextos GL creados dentro de la misma aplicación no son recursos compartidos. Esto significa que obtiene un contexto de recursos GL aislado por superficie. IE: Si tiene una aplicación que usa múltiples superficies GL, necesitará cargar texturas n veces por superficie, ocupando n veces la cantidad de memoria de textura.

Este comportamiento es diferente en Linux y Windows, de forma predeterminada, los nuevos contextos OpenGL son recursos compartidos (dentro de la misma aplicación). Entonces, si tiene varias superficies GL (en Linux o Windows) dentro de la misma aplicación y carga texturas, solo está cargando recursos de textura una vez, no n veces por superficie.

Algunos de los intentos de piratería que hice para que funcione en Mac son MacGLView1-7.cs :
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

Eventualmente, yo (u otra persona) resolveré el problema para que el comportamiento sea coherente entre plataformas. Simplemente no he tenido suficiente tiempo en el cajero automático.

El documento de OSX para el problema está aquí:

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

Para aclarar, por "contexto GL" me refiero, específicamente, contextos de recursos GL . (Estado del objeto compartido como se describe en el enlace anterior).

Gracias por la aclaración. Ya intenté que funcionara en Windows y Linux.
Windows funciona bien con Wpf, pero en Linux con Gtk # 2 no quiere funcionar: http://hastebin.com/okewirerem
Aquí está el código si desea echarle un vistazo: https://github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

Descubrí que tiene algo que ver con la representación de texto. Si tiene algún otro control sobre el diseño, que representa el texto, se bloquea instantáneamente. Si el texto de ese control está vacío, no se bloquea.

Vaya, eso es raro.

@benklett

Tuve el mismo problema. Si aún no ha encontrado la solución, debe poner esto como la primera línea de su programa 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 (); ....

Esto se debe a algo extraño con x_multithreading o algo así, por lo que OpenTK tiene que entrar allí antes de que gtk se inicialice. No es estrictamente lo primero que tienes que hacer, pero sí bastante temprano.

Muchas gracias por su ayuda, tendré que intentarlo si funciona cuando llegue a casa.

¿Alguna actualización sobre el control OpenGL para eto?

Parece prometedor: https://github.com/philstopford/etoViewport.

Re. etoViewport, podría funcionar con la compatibilidad con WPF y GTK3, pero GTK3 me desconcierta en cuanto a cómo proceder; no es obvio cómo configurar el contexto de El Cairo necesario (para mí).

Duno cómo etoViewport lo está haciendo, pero Gtk 3 tiene un widget GLArea para renderizado OpenGL: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html

¿Alguna actualización en este?

@feliwir etoViewport funciona a partir de ahora para al menos WPF, WinForms y macOS. Sin embargo, no estoy seguro del estado de GTK.

GTK está trabajando en mis pruebas bajo VirtualBox / CentOS 7.xy también VMWare / Linux Mint. Puede haber alguna rareza en el controlador, particularmente en VirtualBox, donde el control OpenGL parece flotar por encima de todas las demás ventanas. Sin embargo, creo que esto podría ser un error en VirtualBox, ya que no se ve en VMWare.

Sin embargo, GTK3 no está implementado para etoViewport.

@philstopford No me gusta la dependencia de OpenTK, ¿hay algún plan para eliminarlo / permitir una devolución de llamada personalizada para la creación de contexto?

Lamento que no te guste, pero no veo por qué. Los parches son bienvenidos, si el enfoque actual no le está funcionando. Realmente no tengo un plan para cambiarlo yo mismo: OpenTK ha sido un caballo de batalla confiable. Esfuerzos anteriores de OpenGL, usé SharpGL y luego ese proyecto se abandonó. Por el contrario, OpenTK se mantiene activamente y es multiplataforma.

Movido a: https://github.com/picoe/Eto.Toolkit/issues/7

@cwensley esto se puede cerrar.