Re: With set_event_compression, most recent motion event is held in waiting
Den 2022-05-26 kl. 14:07, skrev JLM via gtkmm-list: 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. But I do see the problem that you described. With event compression turned off, the last motion event is kept hidden somewhere in GTK until a key or a mouse button is clicked. I made the changes in gdkevents.c in order to find out if the missing motion event is held in GTK itself or in one of its dependencies. I have written a bug report on GTK+ for now https://gitlab.gnome.org/GNOME/gtk/-/issues/4946 ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: With set_event_compression, most recent motion event is held in waiting
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. > > > signature.asc Description: OpenPGP digital signature ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: With set_event_compression, most recent motion event is held in waiting
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. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: With set_event_compression, most recent motion event is held in waiting
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. On Tue, 2022-05-24 at 00:20 +, JLM via gtkmm-list wrote: > 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 > > 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 > > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtkmm-list signature.asc Description: OpenPGP digital signature ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
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 > 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
Re: With set_event_compression, most recent motion event is held in waiting
On Mon, May 23, 2022 at 9:15 AM JLM via gtkmm-list 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 ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: With set_event_compression, most recent motion event is held in waiting
Hi, thanks for taking the time.
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. With the latest code you
can do this:
Move the mouse around inside the DrawingArea. Let go of the mouse so no
further motion events occur. Observe the last event number to be
received.
Press a key on the keyboard. You will immediately see two events, going
by increasing event number. One new motion event, even though the mouse
should be perfectly stationary, and then the key press event.
If you comment out the set_event_compression and then retry the above
test, you will always only receive the key press event, no extra,
lingering motion event.
If this is a problem, I suspect it is in GTK+, but I haven't gotten
around to rewriting the code in C. Another thing I want to try is just
rebooting my computer (I know, crazy Windows concept) just in case that
causes the problem to go away.
Here are some updated files. First the basic .glade file:
False
True
False
True
True
1
And here is an updated C++ file:
#include
#include
class drawingArea : public Gtk::DrawingArea
{
public:
drawingArea(GtkDrawingArea* cObject, const
Glib::RefPtr& builder) : Gtk::DrawingArea(cObject),
eventNum(0) { };
void on_realize(void) override;
int eventNum;
bool on_button_press_event(GdkEventButton* event);
bool on_button_release_event(GdkEventButton* event);
bool on_motion_notify_event(GdkEventMotion* event);
bool on_key_press_event(GdkEventKey* event);
};
void drawingArea::on_realize(void)
{
Gtk::DrawingArea::on_realize();
get_window()->set_event_compression(false);
grab_focus();
}
bool drawingArea::on_key_press_event(GdkEventKey* event)
{
std::cout << eventNum++ << " key pressed\n";
return true;
}
bool drawingArea::on_button_press_event(GdkEventButton* event)
{
std::cout << eventNum++ << " button pressed " << event->x << ":" <<
event->y << std::endl;
return true;
}
bool drawingArea::on_button_release_event(GdkEventButton* event)
{
std::cout << eventNum++ << " button released " << event->x << ":"
<< event->y << std::endl;
return true;
}
bool drawingArea::on_motion_notify_event(GdkEventMotion* event)
{
std::cout << eventNum++ << " motion " << event->x << ":" << event-
>y << std::endl;
return true;
}
int main (int argc, char **argv)
{
auto app = Gtk::Application::create(argc, argv, "org.drawarea");
Glib::RefPtr builder = Gtk::Builder::create();
builder->add_from_file("drawarea.glade");
Gtk::Window* mainWindow = nullptr;
builder->get_widget("Window", mainWindow);
drawingArea* drawArea = nullptr;
builder->get_widget_derived("drawing", drawArea);
drawArea->add_events(Gdk::POINTER_MOTION_MASK |
Gdk::BUTTON_PRESS_MASK | Gdk::BUTTON_RELEASE_MASK);
drawArea->set_can_focus(true);
app->run(*mainWindow);
delete mainWindow;
}
On Mon, 2022-05-23 at 16:21 +0200, Kjell Ahlstedt wrote:
> I thought I'd run your program and see what happens, but that's
> difficult without the drawarea.glade file.
> What is it that you suspect is a bug? That you get an extra motion
> event with set_event_compression(false)? Or that you don't get it
> with set_event_compression(true)? It's hardly surprising that the
> number of motion events differ with and without event compression.
> Den 2022-05-21 kl. 03:43, skrev Jason M'Sadoques via gtkmm-list:
>
> > I have a simple drawing area, and I have configured
> > set_event_compression(false). I am printing out motion and button
> > events, and I see while I move the mouse the motion events come
> > out,
> > but then when I stop and press the mouse button, I get one more
> > motion
> > event and then the button press event.
> >
> > Now I can do this because I'm using a trackball, so it is easy to
> > press
> > a button without incurring any further actual mouse motion.
> >
> > When I comment out the line to set_event_compression, I do not see
> > this
> > behavior. So instead when I press the mouse button, I just get a
> > button
> > press, and the coordinates of that button press match exactly to
> > the
> > last motion event.
> >
> > I wonder if someone can either confirm it is a bug, or I really
> > hope
> > that it is a problem I'm doing. I am using GTKMM 3.24.6.
> >
> > Here is a simple example which I compiled with:
> > g++ -o drawtest $(pkg-config --cflags --libs gtkmm-3.0)
> > drawtest.cpp
> >
>
signature.asc
Description: OpenPGP digital signature
___
gtkmm-list mailing list
gtkmm-list@gnome.org
Re: With set_event_compression, most recent motion event is held in waiting
I thought I'd run your program and see what happens, but that's difficult without the drawarea.glade file. What is it that you suspect is a bug? That you get an extra motion event with set_event_compression(false)? Or that you don't get it with set_event_compression(true)? It's hardly surprising that the number of motion events differ with and without event compression. Den 2022-05-21 kl. 03:43, skrev Jason M'Sadoques via gtkmm-list: I have a simple drawing area, and I have configured set_event_compression(false). I am printing out motion and button events, and I see while I move the mouse the motion events come out, but then when I stop and press the mouse button, I get one more motion event and then the button press event. Now I can do this because I'm using a trackball, so it is easy to press a button without incurring any further actual mouse motion. When I comment out the line to set_event_compression, I do not see this behavior. So instead when I press the mouse button, I just get a button press, and the coordinates of that button press match exactly to the last motion event. I wonder if someone can either confirm it is a bug, or I really hope that it is a problem I'm doing. I am using GTKMM 3.24.6. Here is a simple example which I compiled with: g++ -o drawtest $(pkg-config --cflags --libs gtkmm-3.0) drawtest.cpp ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
