On 30.08.2014 04:55, Stefan Salewski wrote: > On Sat, 2014-08-30 at 03:46 +0200, Stefan Salewski wrote: >> Just for fun I have tested with GTK 3.12 for Nimrod, but I can not see >> an effect of event compression... (It was necessary to put >> set_event_compression() after window.show_all(), seem that Ruby >> bindings >> ensure that a Gdk window is always available, while plain Nimrod >> bindings needs realize before.) I may try plain C tomorrow, or in >> winter. > > OK, I should not complain to loud -- indeed I moved the mouse pointer > fast... > > I have just added a time output to the Nimrod program: > > echo round(event.x), " ", round(event.y), ":", event.time > > stefan@AMD64X2 ~/fups $ ./test > 3 461:32626589 > 54 459:32626605 > 99 459:32626617 > 144 459:32626628 > 183 466:32626640 > 232 468:32626652 > 281 468:32626664 > 344 468:32626676 > 393 468:32626689 > > So we get an event every 12 ms -- more makes no sense for a 60 Hz TFT > display. > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list > Ok, as far as I am concerned disabling the event compression solves the problem. In my case I have optimized the drawing routines such that the time needed to process a motion event (i.e. to draw a new segment onto the canvas) is << 1ms. Since my code is able to keep up with the rate at which uncompressed events are generated disabling the compression makes sense in my case. Thank you for the suggestion, I appreciate the help :) ax487 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
