In short: is there any kind of OpenGL Render Control planned which is being used in conjunction with OpenTK?
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.
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.
Indeed, that would be a way to do that.
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
Progress has been made on an OpenGL control for eto here:
Is this OpenGL Control in a usable state?
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?
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:
Eventually, I (or someone else) will nail down the problem so the behavior is consistent cross-platform. Just haven't had enough time atm.
The OSX doc for the issue is here:
To clarify, by "GL context" I mean, specifically, GL resource contexts. (Shared object state as described in the link above).
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
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.
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:
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
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.
Thank you so much for your help I will have to try if that works when I get home.