rattas's picture

Fullscreen and video mode switching support

No actual development has started on the Fullscreen support, but a little discussion
ahead of time can only help clarify things.

What ought "Fullscreen support" to actually include?

--Allow matching between desired video mode features (width, height, refresh rate etc)
and actual video modes supported by the graphics hardware and display.
Perhaps something like a method that returns a list of matched modes.

--Correctly handle special events like Alt-Tab in Windows.
This means switching back and forth between previous desktop video mode and the app's
chosen video mode, de/coupling keyboard and other input devices appropriately.

--Ensure that when the system is shut down/GameWindow destroyed the previous video mode
will be restored automatically so that every application doesn't have to go and
implement that on its own.

What else?


Comments

Comment viewing options

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

First of all, there is some code in an old version of OpenTK that performs mode switching. It might be worth taking a look (edit: check WindowContext.SetFullScreen and X11Context.SetFullScreen)

More or less, we want the following on a fullscreen/window switch.

  1. Store existing mode. Most OS'es can restore modes on their own, but some might not be able to.
  2. Match requested mode against the list of supported modes.
  3. Request a mode switch.
  4. Remove window borders and resize to full screen.
  5. Hook into Alt-Tab, Ctrl-Esc, Ctrl-Alt-Del if possible to restore modes. Not needed in some OS'es, needed in others.
  6. Restore mode on exit (even on violent exit).

Changes to pixel formats are a bit more complicated, in that we have to destroy/recreate the OpenGL context and window handle (at least on Windows but probably Linux, too). Should be doable though.

The API's needed are already implemented on Windows, so the actual implementation should be quite easy (I'll start looking into xrandr for Linux, as that seems quite widely supported on newer X servers). Designing the API is a bit more difficult though: do we add this functionality directly into GameWindow? Or maybe create a new Monitor (Screen?) class and call that from GameWindow (and possibly GLControl?)

I think the second option might be better from a maintenance standpoint - what do you think?

We'd also need a couple of events to notify changes (and possibly cancel changes before they occur) and it would be nice to have a way to get information on supported display modes. That's all I can think of right now.

rattas's picture

I like the idea of a separate Monitor/Screen/Display class, which can take care of mode matching and switching.

Then the GameWindow class only has to take care of itself. It can have a new toggle method to switch it to "fullscreen"
mode, where its decorations are stripped off and it is made the topmost window.

Window messages for events like "minimized", "window activated" etc. can probably be used to take care of the Alt-Tab etc.
thing.

the Fiddler.'s picture

Agreed. The GameWindow/GLControl/GTKWidget classes would hook into the necessary events and update their state as needed (recreate contexts, remove decorations etc). They would also expose the necessary functions to initiate the mode change, i.e. the whole system could look something like this:
1) User calls GameWindow.ChangeDisplayMode(Width, Height, PixelFormat, Fullscreen, Other attributes) (name as an example)
2) GameWindow.ChangeDisplayMode calls OpenTK.Display.ChangeDisplayMode to perform the actual update.
3) The OpenTK.Display.ModeChanged event is fired to notify GameWindow/the user of the change. GameWindow updates its decorations etc.

(The name should probably be OpenTK.Display as System.Monitor and System.Windows.Forms.Screen already exist)

A small prototype would be very useful here to work out any kinks before commiting further ;)