With set_event_compression, last mouse motion event is held onto
I have a small sample program.
Steps to reproduce
- Run the program.
- Move the mouse inside the window. Observe increasing motion events on the terminal.
- Release the mouse, leaving it stationary inside the window. No further motion events appear.
- Press any key. One new motion event and the keypress appears.
Expected outcome
I do not expect that extra motion event. Further, if I comment out the line in my program regarding gdk_window_set_event_compression(), that extra motion event does not appear.
So it seems that GTK has an extra event that it is not providing to the callback until some other event causes it to spit the lingering event out.
I will attach the program in C, but I was unable to get the event timer or coordinates to print out. I have been developing in C++ with GTKMM, and those aspects work there, so I just spot-checked that the problem isn't with the C++ bindings specifically. I will include that program as well.
How this is observed in practice is that I have something following the mouse, and when I press the mouse button, or release it, that thing moves one pixel in some direction. It is easy for me to see this because I use a trackball, so I can click mouse buttons without moving the mouse. At first I thought it was my trackball, but I got another and observed the exact same issue.
For the example programs I've set it up to make use of a key press so you don't have to be so careful clicking a mouse button, and it also demonstrates that the issue is simply related to reception of another event sort of unclogging the event queue.
Version information
I am using GTK+ 3.24.33 under Arch Linux. Also I am running X.org and XFCE, in case any of that matters.
Additional information
Program in C, GTK+:
Program in C++, GTKMM: