Skip to content

Support for an OpenGL Render Control. #39

azunyuuuuuuu opened this Issue Jul 17, 2012 · 13 comments

6 participants


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

Picoe Software Solutions Inc. member

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
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.

Picoe Software Solutions Inc. member
cwensley commented Aug 4, 2012

Indeed, that would be a way to do that.

Picoe Software Solutions Inc. member

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

Picoe Software Solutions Inc. member
cwensley commented Jun 3, 2014

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

@ghost Unknown referenced this issue in LogicAndTrick/sledge Mar 3, 2015

Cross-Platform UI Suggestion #212


Is this OpenGL Control in a usable state?

Picoe Software Solutions Inc. member

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 commented Aug 22, 2015
  • 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:

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 commented Aug 22, 2015

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:
Here is the code if you want to have a look at it:


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 commented Nov 19, 2015


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
    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.


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.