Adds hint "SDL_WINDOWS_DPI_SCALING" which can be set to "1" to
change the SDL coordinate system units to be DPI-scaled points, rather
than pixels everywhere.
This means windows will be appropriately sized, even when created on
high-DPI displays with scaling.
e.g. requesting a 640x480 window from SDL, on a display with 125%
scaling in Windows display settings, will create a window with an
800x600 client area (in pixels).
Setting this to "1" implicitly requests process DPI awareness
(setting SDL_WINDOWS_DPI_AWARENESS is unnecessary),
and forces SDL_WINDOW_ALLOW_HIGHDPI on all windows.
If the move results in a DPI change, we need to allow the window to resize (e.g. AdjustWindowRectExForDpi frame sizes are different).
- WM_DPICHANGED: Don't assume WM_GETDPISCALEDSIZE is always called for PMv2 awareness - it's only called during interactive dragging.
- WIN_AdjustWindowRectWithStyle: always calculate final window size including frame based on the destination rect,
not based on the current window DPI.
- Update wmmsg.h to include WM_GETDPISCALEDSIZE (for WMMSG_DEBUG)
- WIN_AdjustWindowRectWithStyle: add optional logging
- WM_GETMINMAXINFO: add optional HIGHDPI_DEBUG logging
- WM_DPICHANGED: fix potentially clobbering data->expected_resize
Together these changes fix the following scenario:
- launch testwm2 with the SDL_WINDOWS_DPI_AWARENESS=permonitorv2 environment variable
- Windows 10 21H2 (OS Build 19044.1706)
- Left (primary) monitor: 3840x2160, 125% scaling
- Right (secondary) monitor: 2560x1440, 100% scaling
- Alt+Enter, Alt+Enter (to enter + leave desktop fullscreen), Alt+Right (to move window to right monitor). Ensure the window client area stays 640x480. Drag the window back to the 125% monitor, ensure client area stays 640x480.
The hint allows setting a specific DPI awareness ("unaware", "system", "permonitor", "permonitorv2").
This is the first part of High-DPI support on Windows ( https://github.com/libsdl-org/SDL/issues/2119 ).
It doesn't implement a virtualized SDL coordinate system, which will be
addressed in a later commit. (This hint could be useful for SDL apps
that want 1 SDL unit = 1 pixel, though.)
Detecting and behaving correctly under per-monitor V2
(calling AdjustWindowRectExForDpi where needed) should fix the
following issues:
https://github.com/libsdl-org/SDL/issues/3286https://github.com/libsdl-org/SDL/issues/4712
Since #5602, SDL is intended to have the same ABI across the whole
major-version 2 cycle, so we should not check that the minor version
matches the one that was used to compile an application.
There are two checks that could make sense here.
The first check is that the major version matches the expected major
version. This is usually unnecessary and is not usually done (if we're
calling into the wrong library we'll likely crash anyway), but since we
have the information, we might as well continue to use it.
The second check is whether the version provided by the caller is
equal to or greater than a threshold version at which additional fields
were added to the struct. If it is, we should populate those fields;
if it is not, then we cannot. This is only useful on platforms where
additional fields have genuinely been added during the lifetime of
SDL 2, like Windows and DirectFB (but not X11).
This commit changes the first check to be consistent about only looking
at the minor version, while leaving the second check using SDL_VERSIONNUM
(which will be removed or widened in SDL 3, but it's fine for now).
Resolves: https://github.com/libsdl-org/SDL/issues/5711
Fixes: cd7c2f1 "Switch versioning scheme to be the same as GLib and Flatpak"
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Wine, when a window is programmatically minimized in response
to losing focus, we receive a WM_ACTIVATE for the deactivation,
but GetForegroundWindow still indicates that our window is focused.
This causes an incorrect SDL_WINDOWEVENT_FOCUS_GAINED.
This is probably a Wine bug, but it may take a while to fix and
then for the fix to make its way to users.
According to MSDN, we can also get SIZE_MAXHIDE and SIZE_MAXSHOW,
based on state changes to other windows. It's not clear under
what circumstances this will happen (I saw some docs indicating
it may require multiple application windows), but it doesn't seem
right to treat them as RESTORED.
* Fixes for IME Composition Truncation + Addition of SDL_ClearComposition, SDL_IsTextInputShown
* Fixed: Documentation and code style issues raised during code review.
- allocate ime_candidates on demand
- allow write to the whole allocated memory of ime_candidates
- ensure ime_candcount is set to zero in case the candidates can not be queried for any reason
- move IME_ShowCandidateList, ImmGetContext and ImmReleaseContext to this function
- set ime_candpgsize to MAX_CANDLIST if dwPageSize is zero
- comment out deselection of ime_candsel in case of korean language for the moment (LANG_CHT does not work anyway)
- use assert instead of a check (it is a static function with constant parameter)
- assume it is called with 0 first (simplifies the logic)
- reuse dwLang value instead of a new 'call' to LANG()
The issue is that MS Windows synthesizes a mouse-move event in response
to touch-move events, and those mouse-move events are NOT labeled as
coming from a touch (e.g. GetMouseMessageSource() will not return
SDL_MOUSE_EVENT_SOURCE_TOUCH for those synthesized mouse-move events).
In addition, there seems to be no way to prevent this from happening;
https://gist.github.com/vbfox/1339671 claims to demonstrate a technique
to prevent it, but in my experience, it doesn't work.
Because of this, the "fallthrough" case can't test that the synthesized
mouse-move came from a touch-move, and starts erroneously pressing down
the mouse-button, leading to massive confusion in the client
application.
When mouse buttons are swapped, right mouse button down is the same value as raw mouse button up, and conceptually the two systems use different button masks, so never cache state between the two.
Fixes https://github.com/libsdl-org/SDL/issues/5108
When our keyboard grab hook is installed, GetKeyState() will return 0 for the
GUI keys even when they are pressed. This leads to spurious key up events when
holding down the GUI keys and the inability to use any key combos involving
those modifier keys.
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Clang before Clang 10 and GCC before GCC 7 have problems with using
__attribute__ as a sole statement and warn about a "declaration not
declaring anything", so fall back to using the /* fallthrough */ comment
if we are using those older compiler versions.
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
