xadet's picture

Mac OS X GameWindow Width and Height

I decided to try out something I've been working on for the past few weeks on Mac OS X 10.5.7, I finally managed to get DevIL and other dependencies I use working, but now that I can run that app I've found a problem which I'm completely baffled by.

The screenshot above is using a class I made called Window, which inherits nothing but creates a GameWindow in the constructor. I have 2 properties "Width" and "Height" which both get and set the gameWindow.Width and gameWindow.Height values after the GameWindow has been created. It doesn't draw a thing, simply clears using the colour red, but as you can see it doesn't fill the whole window, no matter what width and height I set the window too that red square stays the exact same size.

I'm really not sure if this is a bug with OpenTK or something I'm doing wrong, any help would be greatly appreciated.

Forgot to mention - I'm using the latest dev rev.


Comment viewing options

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

It seems the resizing code did not update the context (this is not necessary on win32 or xlib, which explains why I missed that).

Can you please test whether this is fixed on rev. 2469?

kanato's picture

This problem is because AGL requires that aglUpdateContext be called whenever the render target is resized. This is exposed through the API via GraphicsContext.Update.

In an earlier version of the code this was done automatically by storing a reference to the graphics context in the CarbonGLNative class, but it looks like the code that stored that reference doesn't get called anymore since the creation of the GLNative window and the context have been separated. Somehow that needs to be worked back in, since this issue will also come up if the user manually resizes the window.

the Fiddler's picture

This means my fix above (rev. 2469) is bogus and will probably result in a NullReferenceException.


The Update() issue can be handled in one of two ways:

  • Move it downstream and have GameWindow call it whenever it receives a Resize event.
  • Call GraphicsContext.CurrentContext.Update() from inside CarbonGLNative.

This leaves the issue of SetFullscreen(), which also needs access to the internal AglContext.

Question: can you make a regular window fullscreen, without an OpenGL context? Is it possible to apply this here? If so, what's the catch (my guess is that we'd lose page flipping and suffer a speed hit, is that correct?)

I don't really like the idea of making the NativeWindow implementation depend on GraphicsContext, but if there's no other solution then so be it.

kanato's picture

Not in the same sense you can on Windows and Linux. On Windows (and Linux?) you make a window the same size as the desktop with a special flag to allow it to cover the taskbar and stuff, but MacOS doesn't allow windows to ever cover the menubar (or usually the dock either). You can do it by capturing the display with CGDisplayCapture, but this is conceptually different, as you don't have a window to draw into, instead you get a Quartz graphics context (analogous to a GDI handle) for the whole screen. At least, that's the model I recall from doing research on this a while back. You can also go full screen via the context directly, but I am not sure if this is just a wrapped up way of calling CGDisplayCapture and attaching the context to the display. After all, there is that weird requirement of specifying a pixel format with the fullscreen attribute, as well as a device to go full screen on, when creating a context if you want to go full screen with it.

Having GameWindow and GLControl call Update is not a bad idea, that's sort of what I had envisioned originally, and then if people use some other control they are responsible for calling Update themselves. I'm not sure calling CurrentContext.Update is the best solution, because if someone has multiple contexts it might call the wrong one, but if they are using GameWindow then it's probably not an issue. In any case, if we can avoid having CarbonGLNative have the dependency on the context then that legacy code should be removed.

the Fiddler's picture

I see. Since we are using the context to switch to fullscreen, NativeWindow won't be able to go fullscreen by itself (which is fine by me). The only remaining issue is how to handle the following use case:

var window = new NativeWindow();
var context = new GraphicsContext(window.WindowInfo);
window.WindowState = WindowState.Fullscreen;

I think it would be enough to add a token to CarbonWindowInfo that instructs AglContext to switch to fullscreen. Since we already require the user to call context.Update() whenever he resizes the window, this should work. This will introduce a slight inconsistency between platforms (Windows/Linux will go to fullscreen in the WindowState.Fullscreen line, while MacOS will wait until the Update() line), but I don't think this can cause any problems.

GameWindow and GLControl keep track of their own contexts, so they can handle this behind the scenes.

kanato's picture

That seems like a reasonable approach. Although we will probably end up with a bunch of support requests from people who developed on Windows and didn't include calls to context.Update when they eventually test on Mac OS. But I suppose most consumers will use either GameWindow or GLControl so it shouldn't be too bad.

xadet's picture

I'm guessing from what's been said you already know but the latest SVN doesn't seem to fix it, same results as before. Thanks for taking the time to look into it, I appreciate it.

kanato's picture

Fix for GameWindow committed in rev. 2479.