kanato's picture

Creating GraphicsContext for a custom control?

I'm updating AgateLib to use OpenTK 0.9.1 from OpenTK 0.9.0, and I'm noticing that there is no public code path to create a GraphicsContext for a control. I can't use GLControl for AgateLib, because AgateLib provides its own custom control for integration with WinForms that works with both DirectX and OpenGL; this way an application can use my AgateRenderTarget without referencing a library external to AgateLib.

It seems like this could be accomplished by providing a public static method somewhere to create a class which implements IWindowInfo (or perhaps IGLControl), as well as a way to call IGraphicsContextInternal.LoadAll(); on the graphics context.


Comments

Comment viewing options

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

I am aware that in 0.9.1, there is currently no way to obtain an IWindowInfo from a Windows.Forms.Control.

It is still possible to associate a GraphicsContext with a custom Control, but you'll have to obtain the IWindowInfo manually (use Control.Handle on Windows, or reflect on XPlatUI on Mono/X11). LoadAll can be called by a simple cast: (context as IGraphicsContextInternal).LoadAll();

If you can wait for a few days, I plan to add a class in OpenTK.Utilities.dll to simplify the creation of IWIndowInfo.

kanato's picture

I can wait; I have a lot of stuff on my to-do list, so I don't plan on doing any release of AgateLib for a few months. Plus this Friday I'm leaving town for a week, so I won't get anything done then.

I was messing around with using an IGLControl object earlier but that's probably unnecessary (it worked though). I wasn't sure that IGraphicsContextInternal was going to be kept public for the release. Having something to create an IWindowInfo in OpenTK.Utilities.dll sounds like a perfect solution.

kanato's picture

I created a patch to add a class with a static method for the OpenTK.Utilities project for creating an IWindowInfo class. I wasn't sure what to name it, so I just called it OpenTK.Utilities.Interop. Let me know if I should change anything.

http://agate.sf.net/download/opentk.interop.diff

the Fiddler's picture

It's a little bit more complicated, as we also need the display connection, screen and root window on X11. Check the WindowInfo getter here.

Also, calling Control.Handle, forces the creation of the Control if it doesn't already exist (firing the CreateControl and HandleCreated events). I don't think this would cause any problems, but it might be a good idea to call CreateWindowInfo in the HandleCreated event and not in the constructor of a Control.

kanato's picture

I see... is there a good reason that isn't done in the X11WindowInfo constructor? Could that stuff be moved into an internal method in X11WindowInfo? Is the stuff in the X11GLControl constructor (setting the CustomVisual and CustomColormap) also necessary?

the Fiddler's picture

IWindowInfo is used for more than just GLControls and XPlatUI is specific to System.Windows.Forms. The logic cannot be moved to X11WindowInfo without coupling it to GLControl (which we don't want).

Setting the visual/colormap is necessary if you want to have any control on the pixel format of the context (otherwise you are limited to what the window already has).

haymo's picture

Just 'ping'ing, that I could also need a way to instantiate a GraphicsContext for a Control not deriving GLControl. Right now I solve this by modifying the OpenTK code (making all nesseccary classes public instead of internal) and copying the functionality of GLControl into my own class. This works, but for the release of my controls I would love to have a cleaner solution by hand. Is the way described above recommended? Or should I wait for the "OpenTK solution"?

the Fiddler's picture

There is nothing wrong with this approach. The "OpenTK solution" will be a simple utility function in OpenTK.Platform.Utilities that does exactly that.

However, you should update your code to the "OpenTK solution" once that becomes available, if only to gain the ability to run on Mac OS X (in the future) :)

kanato's picture

Ok, I was out of town last week so I couldn't make any changes. I've updated opentk.interop.diff with the additions for X11, refactored it and added comments. I've tested it with AgateLib under Windows and Ubuntu 7.10, although it didn't work quite right for a fullscreen setup. Let me know what you think, and also if the location / namespace / name of the class is ok.

the Fiddler's picture

Thanks, I'll commit the code tonight.