Eto: Suporte para um controle de renderização OpenGL.

Não foi especificamente planejado, mas fácil de fazer. Parece que o OpenTK é licenciado pelo MIT, então se encaixaria bem com Eto.Forms.

Pode haver algumas complicações, pois você teria que compilar seu aplicativo com referências diferentes com base na plataforma de destino, a menos que Eto.Forms tivesse uma espécie de wrapper em torno do OpenTK, o que eu não gostaria necessariamente de fazer.

Eu observei que você tem DLLs de plataforma separadas para Windows, Gtk e Mac, não poderia ser esse o local para colocar o código específico da plataforma.
para usar o OpenTK, você precisará fazer referência a um OpenTK.dll independente de plataforma comum e um específico de plataforma cujo código pode ser adicionado ao Eto.Platform. *. dll existente, uma vez que esses provavelmente já contêm as referências necessárias.

Tenho trabalhado modificando e eliminando um fork do OpenTK encontrado em https://github.com/hultqvist/opentk
Mas esteja avisado que fork tem algumas modificações importantes que o tornam incompatível com o projeto Opentk original (principalmente usando vetores de coluna).

Ainda assim, a parte de que estou falando não mudou nesse sentido, especificamente os projetos OpenTK.GLControl e OpenTK.GLWidget para Windows e Gtk respectivamente, acho que um semelhante poderia ser feito para Mac, mas atualmente a única implementação é do original Classe de gamewindow do OpenTK.

Na verdade, essa seria uma maneira de fazer isso.

Eu olhei um pouco - é uma pena que o MonoMac use um OpenTK personalizado integrado ao MonoMac.dll. Podemos ter que criar um invólucro em torno de toda a API, o que seria lamentável

Progresso foi feito em um controle OpenGL para eto aqui:

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

Este controle OpenGL está em um estado utilizável?

Eu não experimentei, então não tenho certeza, embora tenha visto capturas de tela dele funcionando no SharpFlame .. @bchavez , você tem mais informações sobre o estado do seu controle OpenGL?

• Eto.Gl - O _Eto Control_, mas ainda não formalizei a API.
• Eto.Gl.Windows - GL específico da plataforma deve funcionar como está no Windows usando Eto.Gl .
• Eto.Gl.Linux - GL específico da plataforma no Linux precisa ser atualizado devido a algumas novas mudanças eto . Não deve ser difícil atualizar, apenas não tive tempo suficiente.
• Eto.Gl.Mac - Problema _gotcha_ um tanto difícil que ainda preciso resolver.

O único problema principal no Mac / OSX é, por padrão, novos contextos GL criados no mesmo aplicativo não são compartilhados de recursos. Isso significa que você obtém um contexto de recurso GL isolado por superfície. IE: Se você tem um aplicativo que usa múltiplas superfícies GL, você precisará carregar texturas n vezes por superfície, ocupando n vezes a quantidade de memória de textura.

Esse comportamento é diferente no Linux e no Windows, por padrão, novos contextos OpenGL são recursos compartilhados (dentro do mesmo aplicativo). Portanto, se você tiver várias superfícies GL (no Linux ou Windows) dentro do mesmo aplicativo e carregar texturas, você só estará carregando recursos de textura uma vez, não n vezes por superfície.

Algumas das tentativas de hacking que fiz para fazê-lo funcionar no Mac foram MacGLView1-7.cs :
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

Eventualmente, eu (ou outra pessoa) irei resolver o problema para que o comportamento seja consistente entre plataformas. Só não tive tempo suficiente atm.

O documento OSX para o problema está aqui:

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

Para esclarecer, por "contexto GL" quero dizer, especificamente, contextos de recursos GL . (Estado do objeto compartilhado conforme descrito no link acima).

Obrigado pelo esclarecimento. Já tentei fazê-lo funcionar em Windows e Linux.
O Windows está funcionando bem com Wpf, mas no Linux com Gtk # 2 ele não quer funcionar: http://hastebin.com/okewirerem
Aqui está o código, se você quiser dar uma olhada nele: https://github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

Descobri que tem algo a ver com renderização de texto. Se você tiver algum outro controle no layout, que renderiza o texto, ele trava instantaneamente. Se o texto desse controle estiver vazio, ele não travará.

Uau, isso é estranho.

@benklett

Eu tive o mesmo problema. Se você ainda não encontrou a correção, deve colocá-la como a primeira linha do seu 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 (); ....

Isso é por causa de alguma coisa maluca com x_multithreading ou algo assim, então o OpenTK tem que entrar lá antes que o gtk seja inicializado. Não estritamente a primeira coisa a fazer, mas bem cedo.

Muito obrigado por sua ajuda, terei que tentar se isso funciona quando eu chegar em casa.

Alguma atualização no controle OpenGL para eto?

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

Ré. etoViewport, poderia funcionar com suporte a WPF e GTK3, mas GTK3 me intriga sobre como proceder - não é óbvio como configurar o contexto Cairo necessário (para mim).

Duno como etoViewport está fazendo isso, mas Gtk 3 tem um widget GLArea para renderização OpenGL: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html

Alguma atualização sobre este?

@feliwir etoViewport funciona a partir de agora para pelo menos WPF, WinForms e macOS. Não tenho certeza do status do GTK embora.

GTK está trabalhando em meus testes no VirtualBox / CentOS 7.xe também VMWare / Linux Mint. Pode haver alguma estranheza no driver, particularmente no VirtualBox, onde o controle OpenGL parece flutuar acima de todas as outras janelas. Eu acho que isso pode ser um bug no VirtualBox, embora não seja visto no VMWare.

GTK3 não está implementado para etoViewport, no entanto.

@philstopford Eu não gosto da dependência do OpenTK. Algum plano para removê-lo / permitir um retorno de chamada personalizado para a criação de contexto?

Lamento que você não goste, mas não estou vendo por quê. Patches são bem-vindos, se a abordagem atual não estiver funcionando para você. Eu realmente não tenho um plano para mudar isso: OpenTK tem sido um burro de carga confiável. Esforços anteriores de OpenGL, eu usei SharpGL e então esse projeto foi abandonado. Em contraste, o OpenTK é mantido ativamente e multiplataforma.

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

@cwensley isso pode ser fechado.