Otherwise only the display resolution is changed, but the SDL window size
(and for example the window-surface size) aren't adjusted accordingly
and thus don't fill the whole screen.
See #3313
.. and maybe other platforms as well (though X11 was not affected)?
The issue was that passing a higher resolution than the current desktop
resolution to SDL_CreateWindow() with SDL_WINDOW_FULLSCREEN didn't switch
to that resolution (even though it did switch to lower resolutions).
When creating a fullscreen window, window->fullscreen wasn't even set
at all (only zeroed out), setting it only happened if the user explicitly
called SDL_SetWindowDisplayMode(). So without that, SDL_CreateWindow()
-> SDL_UpdateFullscreenMode() -> SDL_GetWindowDisplayMode() used the
resolution from window->windowed.w/h which were limited to the desktop size
due to some weird combination of WIN_AdjustWindowRectWithStyle() and
WIN_WindowProc() being called after a call to SetWindowPos().
fixes#3313
This prevents a race if two threads that need d-bus try to init it at the
same time. Note that SDL_Init will likely handle this from a single thread
at startup, but there are places outside of init where one might trigger
D-Bus init, like setting thread priority (a common first thing for a new
thread to do) resulting in SDL trying to use RTKit.
Fixes#4587.
This reintroduces the fix from 0e16ee8330, but just marks
the viewport state as dirty after a clear that needs to expand the
viewport to fill the render target, as we'll need to also reset
the orthographic projection state elsewhere, and that won't
happen if we clear the dirty flag here.
Fixes#4210.
(again.)
(...sorry...!)
- Fixed the markdown.
- Code can now be exited by pressing ESC.
- Cleans up and returns from main()
- Mushed all the `if (x) { return 0; }` blocks into else ifs.
The LINKER variable is set in configure.ac as either 'CC' or 'CXX'
where it is then passed to the created Makefile. This fails with
slibtool which can't find the 'CC' file and can be fixed by correctly
setting the LINKER variable to an actual Makefile variable like '$(CC)'
or '$(CXX)' instead. Presumably GNU libtool does some magic here to
hide the issue.
The Renderer logical scaling code scales mouse coordinates, and needs to
take the window DPI into account on HIGHDPI windows. However, the
variable which tracks this, renderer->dpi_scale, is set once when the
renderer is created, and then not updated. In the event that the window
is moved to another screen, or the screen DPI otherwise changes, this
will be outdates, and potentially the coordinates will be all wrong.
So let's update the dpi_scale on the SIZE_CHANGED event: it's at least a
possibility that this will be issued on some OSes when DPI changes, and
it's otherwise already handled by SDL_Renderer's event filter.
The $(objects) directory (usually build/) may not have been created by
the time the wayland-scanner protocol files are being compiled. The
$(gen) directory is explicitly made with mkinstalldir, but the final
object file (and gcc dependency files) need to go into $(objects).
For whatever reason, this only ever seemed to occur if --disable-shared
was set.
Note that this commit doesn't regenerate ./configure, as there were a
few unexplained, unrelated differences my version of autoconf created,
as as an autotools novice, I didn't want to poke that bear just yet.
This hopefully should fix#3689
Otherwise you might have set the viewport to the full size of
the render target in SDL's API but this change hasn't been
transmitted to Direct3D yet by the time we attempt to clear.
Fixes#4210.
SDL_AddHintCallback() uses SDL_malloc(), which means this would
run before main(), so the app wouldn't be able to supply its own
replacement SDL_malloc() implementation in time.
This code was moved to under SDL_Init. Since the hint callback
already makes efforts to not override the app manifest's
orientation settings, this is safe to move until after pre-main()
startup.
Fixes#4449.
This removes the CM_Register_Notification code on WinRT. Note
that this API _is_ available to UWP apps as of Windows 10.0.17763
(version 1809, released October 2018), according to:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-devices-config-l1-1-1dll
So it might be worth readding with some sort of preprocessor check
for minimum targeted version, or whatever is appropriate for WinRT
development.
This was causing configure events to not inform SDL of window size
changes, even when they were based on resizes that we fully expected. The
result was fullscreen->windowed not working at all, because it would
retain the desktop resolution instead of reverting to the floating size
that it had before moving to fullscreen mode.
Fixes Super Hexagon fullscreen toggling.
The flush has been removed in e5f9fae034.
Unfortunately, even though ideally the flush shouldn't be necessary,
our resize sequence isn't... well, perfect, and removing that flush causes
tons of troubles.
We're also still flushing in other paths where the window size can be
changed by the compositor and where we may potentially have to obey that
change, like in Wayland_MaximizeWindow.
This also removes the hack introduced in 7f261d3b76,
which introduces problems with protocol violations and seems to not be
necessary when flushing.
We have issues with correct resize sequence and happen to commit old-sized
buffers even after configure event for the new size has been already
acknowledged. While the reason for that stays unknown, let's at least
workaround the problem by faking window geometry into expected size.
This does not fix visual glitch on e.g. fullscreen toggling, but having
a split-second glitch is still a much better outcome than being
terminated by the compositor for protocol violation.
This was causing window changes to completely break, resulting in broken
decorations and bizarre frame timing, I don't know what exactly it's doing
but it's not good. Kept the libdecor_frame_is_floating logic, at least.
Sam Lantinga
Daniel Gibson
Ryan C. Gordon
Cameron Gutman
Ethan Lee
Ozkan Sezer
orbea
David Gow
Sebastian Krzyszkowiak