If a touch-down event is received for an existing touch-ID, that
probably means the operating system lost it, and that the missing
touch-up should be synthesized, to keep the client state coherent.
This reverts commit c477768e6f.
We want to add the sentinel anytime we pump inside SDL_WaitEventTimeout() to avoid pumping again the next time through, as a performance optimization.
We don't want to catch explicit SDL_PumpEvents() calls by the application with
our polling check to avoid stale data. If the call to SDL_PumpEvents() produced
no events, there will be a sentinel sitting in the queue that will cause
SDL_PollEvent() to immediately return 0 next time it is called.
Our SDL_WaitEventTimeout() implementation avoids this issue by always popping
an event after calling SDL_PumpEvents(). This will remove the new sentinel if
we didn't get any new events.
Add a new flag to avoid suppressing EINTR in SDL_IOReady(). Pass the
flag in WaitEventTimeout() to ensure that a SIGINT will wake up
SDL_WaitEvent() without another event coming in.
* Avoid unnecessary SDL_PumpEvents calls in SDL_WaitEventTimeout
* Add a sentinel event to avoid infinite poll loops
* Move SDL_POLLSENTINEL to new internal event category
* Tweak documentation to indicate SDL_PumpEvents isn't always called
* Avoid shadowing event variable
* Ignore poll sentinel if more (user) events have been added after
Co-authored-by: Sam Lantinga <slouken@libsdl.org>
Instead do an absolute elapsed time check since the start of the wait. If that is exceeded during any iteration the routine exits as the timeout has elapsed.
There were a few places throughout the SDL code where values were
clamped using SDL_min() and SDL_max(). Now that we have an SDL_clamp()
macro, use this instead.
This is the mouse focus except in the case where relative motion is enabled and the mouse is over a window floating on top of the application window (e.g. the taskbar)
This fixes restoring the cursor clip rectangle after the mouse has moved off of the window.
Also try to better synchronize cursor visibility with mouse position changes when changing relative mode. This doesn't work perfectly, but it seems to improve things on Windows.
When relative mode is enabled and not using warp mode, the cursor is
being clipped to the window. Therefore there is no reason to restore the
cursor position to the center.
Avoiding the warp to center simplifies mouse position event flow, as we
are no longer potentially receiving mouse events for the automated
movement of the cursor and can be (mostly) assured that an incoming
event from the windowing system is that of external means.
Not only is it more efficient to batch process pending events, it is
necessary for correctness with the Win32 backend. WIN_PumpEvents() runs
periodic updates of the cursor clip region and disambiguation of
left and right shift keys in addition to standard event processing.
Based on a patch by Jochen Schäfer <josch1710@live.de> :
On a T420 pressing the ACPI button for volume control, big scancodes
were emitted. This was causing an overflow, because missing guards.
We can be in a situation where we receive a win32 hook callback on the same
thread that is currently waiting. In that case, we do still need to trigger
a wakeup when an event is pushed because the hook itself won't necessarily
do that (depending on what we return from the hook).
When possible use native os functions to make a blocking call waiting for
an incoming event. Previous behavior was to continuously poll the event
queue with a small delay between each poll.
The blocking call uses a new optional video driver event,
WaitEventTimeout, if available. It is called only if an window
already shown is available. If present the window is designated
using the variable wakeup_window to receive a wakeup event if
needed.
The WaitEventTimeout function accept a timeout parameter. If
positive the call will wait for an event or return if the timeout
expired without any event. If the timeout is zero it will
implement a polling behavior. If the timeout is negative the
function will block indefinetely waiting for an event.
To let the main thread sees events sent form a different thread
a "wake-up" signal is sent to the main thread if the main thread
is in a blocking state. The wake-up event is sent to the designated
wakeup_window if present.
The wake-up event is sent only if the PushEvent call is coming
from a different thread. Before sending the wake-up event
the ID of the thread making the blocking call is saved using the
variable blocking_thread_id and it is compared to the current
thread's id to decide if the wake-up event should be sent.
Two new optional video device methods are introduced:
WaitEventTimeout
SendWakeupEvent
in addition the mutex
wakeup_lock
which is defined and initialized but only for the drivers supporting the
methods above.
If the methods are not present the system behaves as previously
performing a periodic polling of the events queue.
The blocking call is disabled if a joystick or sensor is detected
and falls back to previous behavior.
By default, we will minimize the window when we receive Alt+Tab with a
full-screen keyboard grabbed window to allow the user to escape the
full-screen application.
Some applications like remote desktop clients may want to handle Alt+Tab
themselves, so provide an opt-out via SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED=0.
Sam Lantinga
ulatekh
Cameron Gutman
Sylvain
Cacodemon345
Brick
Ethan Lee
David Gow
Dean Herbert
Ozkan Sezer
Francesco Abbate
Ankith