On 11/12/19 10:04 AM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
__wine_send_input was introduced at a time when SendInput was handled in the graphics drivers, we don't do that anymore and it makes little sense to go through user32 for user input now.
Signed-off-by: Rémi Bernon rbernon@codeweavers.com
Notes: Making the request directly also bypasses the wait for the reply, as well as some state update, but I think it should be alright as we should not care about native vs injected input processing order.
I'm not entirely sure of the implication of not waiting for the reply, but I think graphics drivers don't care about it. It also has a beneficial impact on performance in the case where we would have waited for the reply on each input.The wait is necessary for hook processing. The state update is also needed to avoid redundant server calls. It doesn't look like this series is going in the right direction.
Regarding the hooks, I assumed that if we are processing input events, it means that the current thread is already in a message processing loop, so the hooks would eventually be processed if they belong to the same thread. Although maybe that would depend on the message filters?
If they belong to another thread, it means that if for any reason that thread is not processing its messages, input events coming from the user would block the message loop instead of just being queued to the hooking thread. Maybe it's also something we expect?
Anyway, thanks for the comment, I'll drop this.