kanato's picture

Creating GraphicsContext objects for arbitrary WinForms controls.

I have committed some code which provides a public API for the creation of a GraphicsContext for any WinForms control. It's in OpenTK.Platform.Utilities. [1] It works by calling OpenTK.Platform.Utilities.CreateGraphicsContext passing in a graphics mode, and either the control or the control handle. Two outputs are given, the GraphicsContext object, and an IWindowInfo object. An IWindowInfo object can be created separately if desired by calling CreateWindowInfo.

Initially I was having problems with the code on Linux, it was giving errors making the context current. Then I realized that I was getting context creation errors when running glxinfo and glxgears. Since it was long past due that I upgrade to OpenSuSe 11.0, I did that and now have tested this code under Mesa and with the latest nvidia driver and it works.

The point of the above paragraph is I think I found another bug, which was a bit of a red herring when I was troubleshooting the context creation. In the X11GraphicsMode code, the out value from Glx.GetConfig(*,*,GLXAttributes.Samples, out samples) seems to be just random. Sometimes it was negative, and then when the default graphics mode was created it would throw an exception saying samples had to be positive. Has this been encountered before?

[1] Originally I had planned to put this in the OpenTK.Utilities.dll but it seems to fit better in OpenTK.Platform.Utilities.


Comments

Comment viewing options

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

Pardon my ignorance - but what is the use case of creating a graphics context ontop of any control? I guess it could be used to rendering OpenGL to a button or something?

kanato's picture

Well, I suppose so you could render to a button, but the idea is really for if you want to use a panel or UserControl or something other than GLControl. The reason for doing that would be for a library like AgateLib, which abstracts away the underlying API, so it can run with either OpenGL or DirectX. AgateLib provides a UserControl to render to which can be used with either the DirectX or OpenGL backend (and eventually, XNA or SDL). But for the same control to be used for DX without forcing the application to reference a GLControl, AgateLib needs to be able to create a GLContext for its own usercontrol.

objarni's picture

Thanks for the clarification!

haymo's picture

... and thanks for the commit! I am in need of the separate creation possibility, since our controls are abstracted exactly the same way as AgateLib. Right now, I have to implement the creation functionality manually on every OpenTK update. Next time this can be at lot easier. :) I somehow missed the results for the "Write access to svn" issue: are your contributions in the official svn now? (just too lazy to check)

the Fiddler's picture

They are in :)