Commits on Source (12)
-
If there is no display, then not only we cannot translate the coordinates to something meaningful, but the filters and the mouse event callback are not initialised yet, so there is also nothing to pass the events onto (see what ProcessMouseState() does).
f0f938f5 -
Unlike the event callback, which is only known at start time, there are no particular reasons to reinitialise this every time. This simplification preemptively avoids what would have been a third dependency from mouse event processing on the display lock in following changes.
aa72e499 -
This moves what was left of mouse event processing out of the video output thread. Thus mouse events are processed directly from the emitting thread (UI for embedded video, window provider otherwise), just like keyboard events. This removes the lesser bottleneck in mouse event processing (the bigger bottleneck being the display lock to be removed further on). Incidentally, this also removes the last remaining event type from the video output queue.
59b26270 -
1fc75b08
-
This had become a no-op.
30671b46 -
4322cf2f
-
The return value was always VLC_EGENERIC, so remove it. Rename the function to vout_control_Wait() as all it ever does now is wait, now that there is no control queue.
28994fc3 -
0e4ed0f6
-
a2ad11fe
-
Holders typically expect to be processed as soon as possible (e.g. toggling pause) as response to user interaction. Waking up the control queue on the other hand was only meant to avoid dead lock, and nowadays only serves to avoid waiting for the control deadline. Note that we do not really need to recheck the pending count in the original wait loop. If we get there, we will wait for the time-out and let holders pass anyway.
d7b6277c -
The deadline is a constant for the span of the function call, so we can check it once and notionally propagate the value within the for loop. Then the for loop is essentially a no-op when the deadline equals VLC_TICK_INVALID, so that leaves only the case of a valid deadline.
4620c3d7 -
4afe59d8