JTalton's picture

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

When trying to call OpenTK.Graphics.GL.LoadAll() in my application that uses my GTK GLWidget I get

Unhandled Exception: System.InvalidOperationException: No GraphicsContext available in the calling thread.
at OpenTK.Graphics.GL.LoadAll () [0x00000]
at MainWindow..ctor () [0x0000d] in /home/jtalton/GLTest/GLTest/MainWindow.cs:13
at GLTest.MainClass.Main (System.String[] args) [0x00005] in /home/jtalton/GLTest/GLTest/Main.cs:11

OpenTK 0.9.0 did not have this issue.

The problem is that the GTK Sharp GLWidget does not create a graphic context until it is "realized". This is so that there will be a valid window and device handle to use when creating the graphics context.
I tried to hook the OpenTK.Graphics.GL.LoadAll () in the the realized event but for some reason my test code does not render anything. It does not crash though.
A problem with adding this call to the realized event is that there may be multiple GLWidgets in an application.

Any suggestions?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
JTalton's picture

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's picture

On the subject of better error reporting.

It would be interesting to try to use the "Conditional" attribute to validate OpenGL calls and such.

void SetStateInBegin()

public static void Begin(OpenTK.Graphics.BeginMode mode)

Basically if "Debug" is defined then this will call SetStateInBegin().
If "Debug" is not defined, the JIT will optimize the call completely out of execution.

Then errors could be thrown if gl calls that need to be in a glBegin are called outside of it, etc...
It would be a lot of work but would be great at identifying problems.

* Not sure if "Debug" would be appropriate for this... maybe "DebugGL" etc... so it could be turned on and off.

the Fiddler's picture

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

Darian's picture

@Fiddler: I know it's an awfully ugly hack but it enables running the program. less some flickery that's yet to be figured out its source, the usual suspects are: the GLcontrol layout, compiz (disabling improves but not abolishes).

Am eagerly waiting for this,

- Darian

JTalton's picture
using System;
using Tao.Sdl;
using OpenTK.Graphics;
using System.Threading;
public class SDLExample
    public static void Main()
        Sdl.SDL_SetVideoMode(640, 480, 32, Sdl.SDL_OPENGL | Sdl.SDL_DOUBLEBUF | Sdl.SDL_RESIZABLE);
        GL.LoadAll(); // No GraphicsContexts in calling thread
        GL.ClearColor(1.0f, 0.0f, 0.0f, 0.0f);
        Thread.Sleep(5000); // 5 Seconds

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

JTalton's picture

Did we ever come up with a plan for this? I get pinged every once in a while from someone who wants to use the GLWidget and the latest version of OpenTK.

the Fiddler's picture

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.

JTalton's picture

Thanks. No hurry.