kanato's picture

Minor questions

Some minor questions I have about the specific design in OpenTK.

Why have GraphicsContext and IWindowInfo separate?
Is there a use case for using a GraphicsContext with two different IWindowInfo objects? This seems like it would be most applicable for GLControl, but unless I am mistaken GLControl does not have any public property which returns its IWindowInfo. In OSX a GraphicsContext must be bound to a window, and I haven't been able to test it thoroughly, but think its framebuffer might be the size of the window that it's bound to, so if you want to render to two windows that are different sizes you must rebind the GraphicsContext by calling aglSetDrawable before drawing to the framebuffer. This is probably mostly coming from my ignorance but it seems like things could be simplified if the classes implementing IWindowInfo were merged into the native graphics context classes.

The dictionaries in the platform DisplayDevice implementations could be eliminated by adding a property "internal object Tag { get; set; }" on the DisplayDevice which is used to associate the DisplayDevice objects to their platform-specific handles (int on X11, string on Windows, IntPtr on MacOS). The same approach could be used for DisplayModes, and we could get rid of the nested List> inside X11XrandrDisplayDevice. This is just a minor code-cleanup, not a serious issue either way.

GameWindowState tester
Sometimes I notice when changing to full screen and back on the macos branch (Windows and MacOS), the text no longer appears in the upper left hand corner. I'm pretty sure it's just a problem of getting the events right but I haven't really looked into it deeply yet. What needs to happen here? I assume it's resize event -> glViewport -> gluOrtho projection?


Comment viewing options

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

[Why have GraphicsContext and IWindowInfo separate?]
The reason is that a contexts can be created on one control and then bound to others if desired - at least on win32 and X. For example (in WinForms terminology), you could have a windowed mode where the context is bound to a custom Control and a fullscreen mode where the same context gets bound to a fullscreen Form.

GLControl is a control + context together, so it doesn't make sense to separate the two.

I also think the framebuffer has the same size as the window, but I haven't checked either.

(Have to run now, more later!)

kanato's picture

I see that it can be used in that way, where a context can be switched from one control to another or a fullscreen form, but my question is, is that really useful? You can always create a second context for a second control which shares with the first, which AFAIK has only a tiny memory penalty so I don't really see what is gained by the extra complexity. If they were merged we could have something like GraphicContext.SetRenderWindow(Control target) or something if this feature was really needed.

Btw, I added a third question.

the Fiddler's picture

Ok, here goes! :-)

[Why have GraphicsContext and IWindowInfo separate?]
That was just an example. There is one more reason: it allows porting to other systems, without modifying the context classes (or indeed, the library).

For example, imagine that you'd like to integrate with Kimono (Qt bindings). As long as you can instantiate the relevant IWindowInfo and fill it with the necessary information, you don't need to modify OpenTK at all. If they were merged, you'd have to add a new GraphicsContext constructor (new GraphicContext(KimonoControl target)) and make OpenTK dependent on Kimono - not good.

I haven't tried to do this yet, but it should be possible to create a collection of tiny "integration" dlls for the main GUI systems (GTK#, Kimono, Cocoa#, wx.Net) with only minor modifications to OpenTK.

Sounds reasonable, although I kinda object to object (maybe a generic base class with string, int, IntPtr specialisations?)

Do you mind logging this to the tracker, lest it gets forgotten?

[GameWindowState tester]
Yes, that is the sequence: Native resize event -> GameWindow.Resize -> update GL.Viewport & projection.

Text is somewhat broken on trunk (and IIRC macos), so it's possible you are observing a side-effect of that.

kanato's picture

[GraphicsContext / IWindowInfo]
Ok, the integration with other windowing systems wasn't something I had thought about much. Okay, what if GraphicsContext just kept a reference to its IWindowInfo, and we provide a method to get/set it? Part of the reason I am pushing for this is because on MacOS when a window is resized, you have to call aglUpdateContext, so the sensible code path would be something like an IWindowInfo.ResizeEvent that could be subscribed to inside GraphicsContext to call Update. At the moment I have this implemented separately in GameWindow and GLControl and it feels a bit hackish, because if one uses an outside method of creating IWindowInfo (as in Platform.Utilities.CreateGraphicsContext) this has to be handled manually. Also, it would allow me to improve the Platform.Utilities.CreateGraphicsContext method which is returning a GraphicsContext and an IWindowInfo through out parameters.

Submitted here, and assigned to myself. I probably won't actually do it until the macos branch is merged into the trunk.

[GameWindowState tester]
Yeah, the text is certainly broken on the macos branch. So I won't worry about too much this until the macos branch is merged with the updated text rendering.