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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
