snake5creator
When starting application with the usual "double click on file" method on Windows, only holding the last click, an unnecessary MOUSEBUTTONDOWN event is sent before the initial MOUSEMOTION event, and mouse button state is stuck in the sense that it takes a subsequent button release, followed by another press for the system to resume sending events (beginning with the next button release / MOUSEBUTTONUP event).
Input event log with held double-click startup: http://i.imgur.com/nypGKR2.png
Without: http://i.imgur.com/yaIqAvV.png
From Melesie
I noticed that when user switches from fullscreen mode to windowed mode and exits application while in windowed mode, Windows performs an additional change of display settings, even though desktop resolution is the same as current one. This causes short black screen to show up. The only way I know of avoiding this is to explicitly switch to default display settings found in registry. MSDN documentation for ChangeDisplaySettingsEx states:
Passing NULL for the lpDevMode parameter and 0 for the dwFlags parameter is the easiest way to return to the default mode after a dynamic mode change.
This would have been a one-line patch to the documentation (specifying that
captures only work as long as the left mouse button is pressed), but I didn't
like that, so I got a little crazy about this instead.
There were several good arguments for this: it's how Windows works with
WM_NCHITTEST, SDL doesn't need to manage a list of rects, it allows more
control over the regions (how do you use rects to cleanly surround a circular
button?), the callback can be more optimized than a iterating a list of
rects, and you don't have to send an updated list of rects whenever the
window resizes or layout changes.
--HG--
rename : test/testdragareas.c => test/testhittesting.c
This should be a "long" which on a 64-bit system is likely to be > 32-bits,
causing XGetICValues() to write past the end of the variable (and stack).
Fixes Bugzilla #2513.
It seems like a net improvement in all the scenarios Sam and I could
think of, and looking at hg history it was added for fullscreen
window management specifically. Much of that code has changed since
then, but maybe it needs to stay there for that and simply be moved
to a fullscreen condition check.
It would solve this issue:
https://bugzilla.libsdl.org/show_bug.cgi?id=2439
As well as cases where on SteamOS, we hide/show specific Steam
overlay windows while expecting them to stay in the background, since
changing the window stacking order really angers the NVIDIA driver.
CR: Sam.
I encountered a little issue: DXGI monitors application's message queue and this behavior interferes with SDL if the application already handles Alt-Enter sequence. I think it is necessary to disable this behavior.
bb174540%28v=vs.85%29.aspx
This change does not include message box support for Windows Phone 8, which does
not offer the same message box APIs that Windows 8.x/RT does.
--HG--
extra : rebase_source : 2047c915117c6711c7cfdc2c1ba3f89450435b8e
(Most of its complaints here are that these ints can be negative, although
they wouldn't been in sane cases. Checking sanity is what assertions do, and
it placates the analyzer appropriately.)
--HG--
extra : rebase_source : 26cde4bbb2ae5fc232d49493c5b9775dcb52c9d7
These scenarios can happen when a GPU is switched, its driver updated, or in
some virtual machines (such as Parallels) are suspended and then resumed. In
these cases, all GPU resources will already be lost, and it's up to the app to
recover.
For now, SDL's D3D11 renderer will handle this by freeing all GPU resources,
including all textures, and then sending a SDL_RENDER_TARGETS_RESET event.
It's currently up to an app to intercept this event, destroy all of its
textures, then recreate them from scratch.
SDL_WINDOWEVENT_FOCUS_LOST is now sent when an app's native window is hidden.
Likewise, SDL_WINDOWEVENT_FOCUS_GAINED is sent when an app's window is shown.
This mimicks behavior seen on iOS and Android.
SDL_WINDOWEVENT_MINIMIZED and SDL_WINDOWEVENT_RESTORED are now sent when the
app's native window is hidden and shown. Previously, these were sent when an
app was suspended and resumed. On Windows 8.x/RT, an app may be sent to the
background without being suspended, which previously meant that
SDL_WINDOWEVENT_MINIMIZED might never have been sent. (On Windows Phone 8,
however, this seems to be different, whereby apps sent to the background appear
to always get suspended.)
SDL_APP_WILLENTERBACKGROUND is now sent as soon as the app is told that it is
about to go to the background. SDL_APP_DIDENTERBACKGROUND is sent via a WinRT
'deferral operation', which is how WinRT gives apps a bit of extra time
(multiple seconds worth) to prepare for an app-backgrounding.
The distinction may be important as the deferral operation's code is always run
in a separate thread. For Direct3D-only apps, this means that between the
two SDL app-backgrounded events, SDL_APP_WILLENTERBACKGROUND will be the only
one run from the main thread. Given that some WinRT operations can only be done
on the main thread (operations to the CoreWindow fall into this category), this
could be important.
It is important to note that pre-deferral code may only have a very short bit of
time to execute code, less so than code run in the deferral operation (where
SDL_APP_DIDENTERBACKGROUND is sent from), which usually gets several seconds to
run.
SDL/WinRT did have support for OpenGL ES 2 via an older version of ANGLE/WinRT,
however its API changed a few months ago, and SDL/WinRT would crash when trying
to use it. It would also occasionally crash when using the older version.
This changeset should make SDL/WinRT work with the latest version, as
available via MS Open Tech's git repository of it at
https://github.com/msopentech/angle
Older versions of ANGLE/WinRT (from either https://github.com/stammen/angleproject
or https://bitbucket.org/DavidLudwig/angleproject) will need to be updated to
MS Open Tech's latest version.
--HG--
extra : rebase_source : 4dbab8a703aaa1d9820bd45297ebbb1ccc895883
