Thanks for looking at this. I guess from what you say, you do not see the problem. I understand, as I think it would become pretty obvious to anyone for example running GIMP. So even if this isn't a problem specific to my program, it may at least be a problem specific to my environment. I have written a bug report on GTK+ for now, and copied the below extra info into that report in case someone on that project can make use of it and get to the bottom of the issue. On Tue, 2022-05-24 at 19:24 +0200, Kjell Ahlstedt wrote:
I made a few changes in gtk/gdk/gdkevents.c, _gdk_event_queue_handle_motion_compression(). gdk_frame_clock_request_phase (clock, GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS) at the end of the function is always called. Without event compression I get an output such as 276 motion 122.582:89.4453 277 motion 123.582:88.4453 278 motion 124.582:88.4453 279 motion 124.582:87.4453 Then when I press a mouse button: (example:17002): Gdk-CRITICAL **: 19:11:02.499: gdk_window_get_frame_clock: assertion 'GDK_IS_WINDOW (window)' failed 280 button pressed 124.582:87.4453 (example:17002): Gdk-CRITICAL **: 19:11:02.587: gdk_window_get_frame_clock: assertion 'GDK_IS_WINDOW (window)' failed 281 button released 124.582:87.4453 The same coordinates as in the last motion event. No motion event when the mouse button is pressed. The critical messages show that my changes of _gdk_event_queue_handle_motion_compression() is not the right solution, but the behavior shows (I believe) that the last motion event before the mouse click is available somewhere in GTK before the mouse is clicked. Den 2022-05-24 kl. 03:40, skrev JLM via gtkmm-list:I have managed to cobble together a program in C which does the same thing and confirmed that it is not a specific GTKMM problem at least.
Attachment:
signature.asc
Description: OpenPGP digital signature