| Summary: | Creating fullscreen window with higher resolution than desktop broken | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Daniel Gibson <metalcaedes> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | cameron.gutman, sezeroz |
| Version: | 2.0.10 | Keywords: | target-2.0.16 |
| Hardware: | x86_64 | ||
| OS: | Windows (All) | ||
| Attachments: |
simple testcase
test log on my system |
||
Created attachment 3850 [details]
test log on my system
"This seems to happen at least with 2.0.9 and 2.0.10" oh, just a clarification: I mean the 2.0.10 "Prerelease" as downloaded from https://www.libsdl.org/tmp/download-2.0.php on 2019-06-29 If you wonder why anyone would even run a game at a higher resolution than the desktop, apparently nvidia has a feature called "DSR" which is like super sampling and from the games point of view is just a higher resolution supported by the GPU driver/display. So even with a FullHD display one might render the game in 4k then - probably especially attractive for older games that otherwise don't stress the GPU very much. Another weird thing I noticed when testing a bit more: If I, after creating the fullscreen window that gets the wrong resolution, call SDL_SetWindowDisplayMode() to set the higher resolution I wanted to have, the display flickers (appears to change mode) and according to SDL_GetWindowDisplayMode() the display then indeed has the desired mode, but SDL_GetWindowSize() still returns the old lower mode?! I think this is working as intended. From https://wiki.libsdl.org/SDL_CreateWindow > If the window is set fullscreen, the width and height parameters w and h will not be used. You have to use SDL_SetWindowDisplayMode() to set the display mode. The window size that you're setting with SDL_GetWindowSize()/SDL_SetWindowSize() are the values that will be used if you ever exit full-screen using SDL_SetWindowFullscreen(). I think that sentence in the wiki is wrong, or maybe based on observation of the broken behavior. (It has been added on August 2015 by "ChrisBush", who AFAIK is no core SDL developer and thus probably not authoritative) And it *does* set the fullscreen resolution - on Linux it works completely as I expect and on Windows it at least sets fullscreen resolutions that are <= the current desktop resolution. To be honest, it not setting the fullscreen resolution for fullscreen windows would be horrible API design: If I can set SDL_WINDOW_FULLSCREEN there to immediately switch to fullscreen mode, then it should use the resolution I provide in the same call. (Sorry if you get several emails like this, we're marking a bunch of bugs.) We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle. Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release. If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug. --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. |
Created attachment 3849 [details] simple testcase Following scenario: I'm running Windows (only tested Win10, but I assume it happens with other versions as well?). I have a display with 1920x1200 native resolution. I switch my desktop resolution to a lower resolution, like 1680x1050. I do SDL_CreateWindow("Test Fullscreen", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 1920, 1200, SDL_WINDOW_FULLSCREEN); Result: I get a fullscreen windows at 1680x1050 Expected Result: Getting a fullscreen window at the requested resolution (1920x1200) - or alternatively, SDL_CreateWindow() failing and returning NULL if it really thinks it can't use the requested resolution. It *does* work the other way around (if display on desktop is running at native resolution and I request a lower one in SDL). It also seems to work on Linux/X11 - I didn't test any other operating systems. I attached a simple testcase that tests this and logs some messages about the requested and received resolution and the supported resolutions to testlog.txt (yes, even in fullscreen mode the requested resolution that it didn't use is listed by SDL_GetDisplayMode()) This seems to happen at least with 2.0.9 and 2.0.10 I'm not very familiar with WinAPI or the SDL Win32 video code, so I didn't really try to debug it myself. Also, I found it confusing that SDL_CreateWindow() sets window->w and window->h to the current display mode bounds, so the requested information is only stored in window->windowed.w/h which *sound* like they should only be for windowed mode - but apparently they aren't, otherwise setting any fullscreen resolution that is not the current desktop resolution should fail, on all platforms, and that is not the case.