Thanks. I took a look at the web page and I'm pretty sure that the described behavior is not what I am observing. For example, I move my mouse around within the DrawingArea, and in the console output I see this (truncated, just showing the end): 2109 649877100 motion 90.9368:79.8589 2110 649877101 motion 90.9368:81.137 2111 649877110 motion 89.6931:82.3807 2112 649877120 motion 88.6931:82.3807 2113 649877129 motion 88.6931:83.3807 2114 649877144 motion 87.6987:83.3807 2115 649877176 motion 87.6987:84.17 2116 649877191 motion 86.9109:84.17 Then I wait a few seconds and press a key and see: 2117 649877194 motion 86.9109:85.1639 2118 649887986 key pressed The timestamp of event 2117 is just right after event 2116, but did not display until I pressed the key. It was recorded, but for some reason the program itself did not receive it (or I made some mistake, and my program is caching things somehow). On Mon, 2022-05-23 at 10:57 -0700, Andrew Potter via gtkmm-list wrote:
On Mon, May 23, 2022 at 9:15 AM JLM via gtkmm-list <gtkmm-list gnome org> wrote:I have updated my test. Now you don't have to press a mouse button, but you can press a keyboard key instead. The problem isn't that I am seeing extra events, the problem is that the extra event seems to be hiding, or stuck in a backend/library queue.The issue is probably even lower than GTK. Maybe libinput? Did you look at the timestamp of the events? https://wayland.freedesktop.org/libinput/doc/latest/timestamps.html The above link suggests some events are delivered out of order
Attachment:
signature.asc
Description: OpenPGP digital signature