Add support for a "windowed" mode

[tlemo]

On Linux, full-screen doesn't always provide a smooth experience (different window managers, Wayland vs X11, ...)

I can see a few ideas to improve this:

1. Default to the desktop resolution (ie. don't try to change the video mode). This would avoid issues with the video mode not being properly restore on exit/crash.

2. Add a "full-screen" option. Turning this off would switch to a "windowed" mode, which doesn't involve video mode changes and it's also a lot more convenient for debugging (at least on single monitor setups)

Thoughts?

[chrxh]

The resolution selection at startup and the display settings are currently implemented in a rudimentary way and are also not bug-free. For example, there is still the bug that the resolution is always set at startup, even when it won't change. This is annoying and I will fix it.

Actually I had the following in mind:

• In the display settings one should be able to switch between fullscreen and windowed mode (as you suggested in 2) ).
• If fullscreen is selected:
  • Allow selection of the monitor (if more than one is available)
  • and whether or not the resolution should be used from the desktop.
    • If not: allow user defined resolution

Default:

• Fullscreen
• If the desktop uses a resolution between 1920x1080 and 2560x1440: do not change resolution (related to your 1))
• For larger resolutions: change to 2560x1440 because the user interface might appear too miniature

What do you think? It would probably be better not to change the resolution at all by default and instead scale the font sizes and widgets depending on the DPI. I haven't dealt with that yet.

[tlemo]

If the high DPI is the main reason for forcing the resolution, I think the basic imgui scaling support could provide an easy solution.

I tried this change on a hidpi setup and it look mostly ok (there are only a few minor UI layout tweaks that may be needed)

[chrxh]

I've now added the ability to switch between windowed and full screen mode and to keep the desktop resolution at startup. I'll include the manual switching of the display resolution in case of full screen in the next step.

I agree that the font scaling looks not so bad. However, the font pixelates when one does it via the global scaling parameter. As an alternative one can also generate the font textures bigger instead. And, of course, the sizes of all imgui windows and a few icons still need to be adjusted automatically. But this should be doable with moderate effort. :)

[tlemo]

Thanks!

A small suggestion: for the "windowed" mode, can you save/restore the window size? (ex. quick prototype)

Also, the full screen / windowed are exclusive settings, and so are the associated screen resolution / window size values. One way to model this, both in the UI and in the underlying data structures, might be through 2 values:

1. mode: [windowed, <...supported video modes...>] -- use string ids for the video modes since the mode indexes may not be stable (ex. changing the monitor)

2. window_size : width x height (used only for the windowed mode)

This, plus using the desktop video mode resolution by default & basic hidpi support, seem to provide a good user experience IMO. Thoughts?

[chrxh]

I like the idea of using string ids too. But I'd like to add another mode-element (actually the default) with the meaning "Full screen, but with the resolution from desktop. I don't want to care what resolution it is.".

I have now implemented this using your suggested mode variable (it's on the developer branch). I'm still testing a bit to see if everything works.

[chrxh]

The automatic scaling of the content should also work now. Thanks for the tip about the window size. I have incorporated it. :)

If there is no objection from your side, can we close this issue?

[tlemo]

I tried it on both Linux and Windows, and it seems to be working beautifully - thanks for taking the time to implement this! The UI looks good on high DPI monitors too.

One minor observation: the "Display Settings" dialog has "Ok/Cancel" buttons but the changes are applied immediately. How to you feel about applying the changes only when "Ok" is selected? (or apply the change immediately and replace "Ok/Cancel" with a "smart" undo button)

PS. no objections to close this issue, thanks for asking

[chrxh]

Ok, super! Currently, changes are applied immediately throughout the program whenever possible to achieve a high degree of responsiveness. I would like to keep this pattern. Maybe it could be more clear to rename the buttons though.