Re: Accuracy of motion events
- From: ax487 <ax487 gmx de>
- To: Stefan Salewski <mail ssalewski de>
- Cc: gtk-list <gtk-list gnome org>
- Subject: Re: Accuracy of motion events
- Date: Mon, 01 Sep 2014 14:12:51 +0200
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 gnome org
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
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]