OpenTK 0.9.1 - Unhandled Exception: No GraphicsContext available in the calling thread.

You are right (I was aware that this would be an issue on this release). The solution would be to have the GTK# GLWidget create a GraphicsContext instead of manually calling wgl/glxCreateContext etc.

To create a GraphicsContext, you'll need an OpenTK.Platform.IWindowInfo object. This object has platform specific implementations, which contain information about a window (window handle and window parent at the very least). Moreover on Windows, the implementation provides a method to get a device context, while on X11 it contains the display connection, screen and root window for that screen.

Now the problem is that these implementations are not public. However, if you modify the *WindowInfo classes in OpenTK.Platform.Windows and OpenTK.Platform.X11 to become public, you should be able to retrieve the necessary info and instantiate a platform-agnostic GraphicsContext as soon as the GLWidget is realized.

The tests for a GraphicsContext will become more rigorous in future versions, as this is a common source of errors (and having your program silently fail/crash is bad). Now, it might be possible to allow a GraphicsContext to "hook" into an existing context (something like a static GraphicsContext.CreateFromCurrentThread), but this leaves the potential for abuse and would have to be coded very careful.

I think the first is preferrable, but the second could be useful in a bnid (e.g. if you have to interface with code you cannot change for some reason). What do you think?

Nice, this makes things a little clearer. It seems there are a few projects that use GTK# or Tao.SDL along OpenTK, which means it might be nice to provide a way to hook into existing contexts.

This should be possible using the wgl/glX/aglGetCurrentContext functions. The question here is, should this be implicit (i.e. a GraphicsContext is created internally whenever an unknown OpenGL context is detected) or explicit?

Regarding multiple contexts, OpenTK internally keeps track of shared contexts it creates. I don't know if there is a way to detect whether two given contexts are shared after the fact (if not, the safest course is to assume they are not). Any ideas on this?

I guess the question is, if there were multiple contexts but not a GraphicsContext for each one, how would OpenTK behave?
Indeed, this is the question.

As long as OpenTK is in control of context creation, it will behave correctly (you can choose which GraphicContexts to share on creation time). If someone else creates the contexts, OpenTK won't be able to detect if they are shared, because there is no API for that. Inconsistencies such as these are unavoidable - which is why OpenTK doens't provide direct access to WGL/GLX.

Fortunately this specific issue isn't significant - OpenTK doesn't keep track of allocated GL resources, so this responsibillity is up to the user. On the other hand this might cause problems in the future, when (and if) the experimental OpenGL GC API is realized. The safest option is to disallow use of this API with non-OpenTK controlled contexts. This is a corner-case however, so I'm not really worried about that.

What's important now is to provide the hooks so that OpenTK works with SDL/GLWidget once more. I'll let you know when that's ready for testing.

I am looking into this but it will be a couple of days.

When you say it renders nothing, do you mean that the original GTK# widget stops functioning?

While a GLWidget built on top of GraphicsContext would certainly be nice (and probably quite simple to implement), we still need to make OpenTK work with Tao.SDL etc. If you can upload a minimal Tao.Sdl or GTK# example, I'll be able to find out what's missing.

Another idea that just occured, is that could create a "dummy" GraphicsContext and fool OpenTK into thinking everything's alright. In fact, one already exists for use in the Visual Studio designer! We'd lose the ability to SwapBuffers() etc through GraphicsContext, but since you can do that through Tao.SDL/GLWidget it's no problem.

How does this solution sound?

Rendering nothing - it just shows up as black with nothing rendered. It's almost like the OpenGL calls I am making don't do anything.

I was thinking about it last night and creating a OpenTK GTK GLControl would require OpenTK having a reference to GTK#. I'm not sure you want that build dependency.

I'll post a simple Tao.SDL example tonight.

Darian - It looks like you are using the WinForms GLControl to create a GraphicsContext and then the GLWidget just happens to work? I guess creating the GLControl would get you passed the issue of getting the Exception on calling GL.LoadAll(), and then the GLWidget would work the way it used to. If the "tests for a GraphicsContext" "become more rigorous in future versions" then this workaround may break. Good to know though.

@JTalton: Thanks, I wasn't aware of this! This helps tremendously with an idea Inertia and I have been discussing: namely, the possibility of adding automatic error handling to the GL bindings.

This will be quite difficult to implement correctly (as there are limitations to where and when you can call GL.GetError()), but it will be very useful once it sees the light of day.

@Darian: GLControl actually creates a second OpenGL context. This doesn't really hurt, but it's a little wasteful. I'm implementing the dummy context solution now, which should solve this problem cleanly.

The TaoFramework dlls can be downloaded from http://www.taoframework.com
This includes the sdl.dll system dll for windows.

Yes, the solution is going to be in 0.9.2. Can't promise exactly when this will appear in SVN, as I'm way too time-limited right now, but it's on the laundry list.