Do not always recreate the window when changing `[sdl]` settings

[johnnovak]

Currently, the window gets recreated and resized when changing pretty much any setting in the [sdl] section. E.g., do the following:

1. Start Staging and resize the window so it's a tall rectangle (just to make it obvious when it changes its size automatically).
2. Execute window_position = 0,0
3. Note the window got resized to its initial size.
4. Resize the window again to a tall rectangle.
5. Execute pause_when_inactive = off.
6. The window size got reset again.

If you do the same in fullscreen, you'll get delays and/or screen flashes instead.

While recreating the window might be necessary in some cases (e.g., when changing the vsync setting or the output mode), we should aim to preserve its size and position whenever practical.

Then for some other settings (such as pause_when_inactive, mute_when_inactive, waitonerror, priority, and probably a few others), we should absolutely leave the window completely alone and neither change its position or size nor recreate it.

[Burrito78]

This will probably close https://github.com/dosbox-staging/dosbox-staging/issues/2549

[weirddan455]

I have looked at this before. There have been similar issues raised #2527 #2549 #3075 #3080 that all boil down to limitations with our config system.

Currently, whenever any setting gets changed at runtime, it calls that section's Destroy() + Init() functions. This leads to doing too much work (SDL re-initing everything on some simple change), bad coupling (SDL's re-init function is coupled to SDL Mapper), and sometimes just not fitting well with architectural decisions we've made elsewhere (Fluidsynth and MT32 being "children" of the general MIDI module).

One solution could be to register a function pointer with every setting (could be the same function for multiple settings if that makes sense). If no function is registered, that means the setting is not changeable at runtime and we display an error to the user. This lets us be more flexible instead of just destroy + init everything.

However, this something I am hesitant to do until after 0.81 because of the pending feature freeze. It would be a large refactor with high risk to cause regressions or introduce additional bugs.

[johnnovak]

Definitely after 0.81.0 @weirddan455, we don't have capacity for this now. Thanks for looking into it and thinking about it, though.

We'll need to discuss this in detail and come up with a plan first if you're contemplating a larger scale refactor, not just addressing the symptoms described in this ticket. There are several moving parts here:

• @kcgen 's module rework he started is related to this
• We are contemplating changing the whole config system too
• Certain settings would be changbeable from the OSD too in realtime
• We want to avoid a big bang style rework, we want to refactor things piecewise
• The SDL rework would also affect things in this specific ticket

So lots of concerns and we need a coordinated approach. I'll create a discussion ticket for this, then we can flesh out ideas and then a sequence of tasks that need to happen, otherwise it's very easy to step on each other's toes with such architectural changes.