Re: With set_event_compression, most recent motion event is held in waiting



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]