Support for an OpenGL Render Control.

[azunyuuuuuuu]

In short: is there any kind of OpenGL Render Control planned which is being used in conjunction with OpenTK?

[cwensley]

Wasn't specifically planned, but easy enough to do. It looks like OpenTK is MIT licensed so it would fit well with Eto.Forms.

There might be some complications though, as you'd have to compile your app with different references based on the target platform, unless Eto.Forms had a wrapper of sorts around OpenTK, which I would not necessarily like to do.

[hultqvist]

I have observed that you have separate platform DLLs for Windows, Gtk and Mac, couldn't that be the location for placing the platform specific code.
to use OpenTK you will need to reference one common platform independent OpenTK.dll and one platform specific whose code could be added to the existing Eto.Platform.*.dll since those most likely already contain the necessary references.

I have been working with modifying and stripping down a fork of OpenTK found at https://github.com/hultqvist/opentk
But be warned that fork has some major modifications that makes it incompatible with the original Opentk project(mainly using column vectors).

Still the part I'm talking about has not changed in that regard, specifically the projects OpenTK.GLControl and OpenTK.GLWidget for Windows and Gtk respectively, I guess a similar one could be made for Mac but currently the only implementation is from the original OpenTK gamewindow class.

[cwensley]

Indeed, that would be a way to do that.

[cwensley]

I looked at this a little - It is unfortunate that MonoMac uses a custom OpenTK built into MonoMac.dll.. We may have to create a wrapper around the whole API, which would be unfortunate

[cwensley]

Progress has been made on an OpenGL control for eto here:

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

[benklett]

Is this OpenGL Control in a usable state?

[cwensley]

I haven't tried it out so I'm not sure, though I've seen screenshots of it working in SharpFlame.. @bchavez, do you have more info about the state of your OpenGL control?

[bchavez]

• Eto.Gl - The Eto Control, but I haven't really formalized the API yet.
• Eto.Gl.Windows - Platform-specific GL should work as-is on windows using Eto.Gl.
• Eto.Gl.Linux - Platform-specific GL on Linux needs updating due to some new new eto changes. Shouldn't be hard to update, just haven't had enough time.
• Eto.Gl.Mac - Somewhat difficult gotcha issue I still need to resolve.

The one major issue on Mac/OSX is, by default, new GL contexts created within the same app are not resource shared. This means, you get an isolated GL resource context per surface. IE: If you have an app that uses multiple GL surfaces you will need to load textures n times per surface, taking up n times the amount of texture memory.

This behavior is different on Linux and Windows, by default, new OpenGL contexts are resource shared (within the same app). So, if you have multiple GL surfaces (on Linux or Windows) within the same app and load textures, you're only loading texture resources once not n times per surface.

Some of the hacking attempts I've made to get it to work on Mac are MacGLView1-7.cs:
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

Eventually, I (or someone else) will nail down the problem so the behavior is consistent cross-platform. Just haven't had enough time atm.

[bchavez]

The OSX doc for the issue is here:

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

To clarify, by "GL context" I mean, specifically, GL resource contexts. (Shared object state as described in the link above).

[benklett]

Thanks for the clearification. I already tried to get it working on Windows and Linux.
Windows is working fine with Wpf, but on Linux with Gtk#2 it does not want to work: http://hastebin.com/okewirerem
Here is the code if you want to have a look at it: https://github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

[benklett]

I found out it has something to do with text rendering. If you have some other control on the layout, which renders text, it instantly crashes. If the text of that control is instead empty, it does not crash.

Wow, that is weird.

[kniteli]

@benklett

I ran into the same problem. If you've still not come across the fix, you have to put this as the first line of your gtk program:

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

This is because of some wacky thing with x_multithreading or something, so OpenTK has to get in there before gtk initializes. Not strictly the first thing you have to do, but pretty early.

[benklett]

Thank you so much for your help I will have to try if that works when I get home.

[shabadan]

Any update on the OpenGL control for eto?

[DanWatkins]

Looks promising: https://github.com/philstopford/etoViewport.

[philstopford]

Re. etoViewport, it could do with WPF and GTK3 support, but GTK3 puzzles me as to how to proceed - it's not obvious how to set up the Cairo context needed (to me).

[harry-cpp]

Duno how etoViewport is doing it, but Gtk 3 has a GLArea widget for OpenGL rendering: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html

[feliwir]

Any updates on this one?

[cwensley]

@feliwir etoViewport works as of now for at least WPF, WinForms, and macOS. I'm not sure the status of GTK though.

[philstopford]

GTK is working in my tests under VirtualBox/CentOS 7.x and also VMWare/Linux Mint. There can be some driver oddness, particularly under VirtualBox, where the OpenGL control seems to float above all other windows. I think this might be a bug in VirtualBox, though, as it is not seen in VMWare.

GTK3 is not implemented for etoViewport, though.

[feliwir]

@philstopford I don’t like the dependency to OpenTK any plans to remove it/ allow a custom callback for context creation?

[philstopford]

I'm sorry you don't like it, but I'm not seeing why. Patches are welcome, if the current approach isn't working for you. I haven't really a plan to change it myself : OpenTK has been a reliable workhorse. Earlier OpenGL efforts, I used SharpGL and then that project became abandoned. By contrast, OpenTK is actively maintained and multi-platform.

[harry-cpp]

Moved to: picoe/Eto.Toolkit#7

@cwensley this can be closed.