News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Why SDL2 now uses fullscreen desktop mode.

Started by DrSuperGood, February 06, 2019, 01:50:34 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

In R8674 the SDL2 backend had its fullscreen mode changed from exclusive fullscreen to fullscreen desktop. The reason for this change is that there appears to be an issue or bug with SDL2 fullscreen display mode changes.

Every display mode change causes the poll event function to block for around 3 seconds. The polling event function is meant to never block. As far as I am aware this issue has not been reported on the internet before.

Minimize and maximize cause a display mode change hence doing such a cycle would block for around 6 seconds. Even starting suffered from this problem adding an extra 3 seconds before the pak select screen appears. While the main thread is blocked polling events, the application is effectively unresponsive. The lost time due to being unresponsive results in the game fast forwarding to catch up. The overall result was a rather bad and unresponsive user experience.

Fullscreen desktop fixes this by always using the display mode of the desktop and hence not requiring any display mode changes. As a result event polling is uneffected and behaves correctly. Not only does the game start faster, but it also minimizes and maximizes highly responsively. The result is fullscreen responsive feel as good as GDI, likely because GDI is operating in a similar way. Technically fullscreen desktop mode is slower as it requires the windows composer to blit a window buffer onto the display buffer. However the extra latency is insignificant for a game such as Simutrans. Performance should pretty much be the same as before since bliting is mostly hardware accelerated on modern OSes.

This change will not effect SLD2 running in windowed mode (default). Windowed mode never performed any display mode changes and hence always performed well as was highly responsive. It is also possible this issue does not occur on all computers, since I only tested it with my Windows 10 machine. However chances are if my Windows 10 machine has the issue, at least someone else will even if not all Windows 10 machines suffer the problem.

Hopefully this is one step closer to the eventual removal/deprecation of the GDI backend. It now is no longer a lot more responsive than SDL2 which was my only reason for using it.

Ters

Actually changing the display mode would cause better visual experience on CRT screens. I don't know if any of those are still around.

Can fullscreen desktop change the aspect ratio? Maybe someone has a 1920x1080 HD screen, but can only run Simutrans at acceptable speeds at 1440x1200. They don't want to run windowed, because then they risk clicking outside the game. They still have the option of changing their display before starting Simutrans, I guess.

I use GDI because it is one less dependency to maintain. The GDI code in Simutrans isn't much maintain, the plain Windows input perhaps. The Windows sound backend is bad, but I don't care for sound anyway.

DrSuperGood

QuoteActually changing the display mode would cause better visual experience on CRT screens. I don't know if any of those are still around.
I agree that it is the best approach, however the way SDL2 implements display mode changing does not work very well, at least for me. 3 second freezes just are not worth it. And when I did manage to get it to change resolution it started to become quite buggy including having its window reappear and even crashing explorer.
QuoteCan fullscreen desktop change the aspect ratio? Maybe someone has a 1920x1080 HD screen, but can only run Simutrans at acceptable speeds at 1440x1200. They don't want to run windowed, because then they risk clicking outside the game. They still have the option of changing their display before starting Simutrans, I guess.
It inherits the desktop resolution. I am unsure if resolution can be changed beyond that. In worst case the player can lower the desktop resolution.

Ters

I just run the game maximized anyway. Fullscreen usually means constraining the mouse to that screen, and I want to be able to switch external music and read about various vehicles (whether it is real-life info from Wikipedia, or in-game parameters from my cheat sheet).

Quote from: DrSuperGood on February 06, 2019, 06:33:51 PMIt inherits the desktop resolution. I am unsure if resolution can be changed beyond that.
It could perhaps add black regions on either side and limit the range of the mouse, but if it is supposed to simply inherit the desktop resolution, does it even take any parameters for display size? Simutrans could perhaps do such a thing itself, but there is likely no need to be preemptive about it.

prissi

I think the problem is that SDL2 behave differently on MAC and Linux (and ... ) On Android one probably have to use the fullscreen mode anyway. Lets hope SDL2 will solve this. (But usually I just use full windows. Are there really any fullscreen players around?)

DrSuperGood

QuoteAre there really any fullscreen players around?
Outside of testing I pretty much only play in fullscreen mode. I am sure more players would if they did not need a command line option or to manually modify a configuration file to do so. If implemented properly alt+tabbing from full screen, even when running in exclusive mode, should be sub second.

Ters

The only games I run in fullscreen are those there are no reason to alt+tab out of under normal circumstances. They also have a tendency to leave the display resolution in something like 800x600, and on Windows 7 and earlier, in 256 colors. Even if they do restore the original display resolution (pretty much only Microsoft's own games) when I alt+tab, that takes about those three seconds.