Re: Accuracy of motion events
On Tue, 2014-09-02 at 11:01 +1000, Lex Trotman wrote:
> As stated before, motion events are only *delivered* per frame, all
> the compress flag does is set it to deliver the motion as one event
> per frame or multiple events per frame. If you have compress true (as
> above) only one event is delivered, on each frame time, so thats the
> time you see. You only get the position at the end of the frame.
>
> If you turn compress off you will get all the events generated during
> the last frame cycle. That allows applications to trace the positions
> that the cursor moved through.
Yes, I understand this, but unfortunately I see no effect. My current
idea was that it may work not for the main window, but it may work for a
drawing area.
So I changed the C code as below, and appended an output snippet.
As you see, time interval is generally about 12 ms. Maybe the limitation
is my computer, it is some years old now, or maybe the mouse device, it
is from Logitech. When I have some time again I may check on another
computer...
//gcc -Wall -o t t.c `pkg-config --libs --cflags gtk+-3.0`
#include
void print_event(GtkWidget *widget, GdkEventMotion *event, gpointer p)
{
printf("%.0f, %.0f: %d\n", event->x, event->y, event->time);
}
int main( int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *darea;
GdkWindow *gdkwin;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
darea = gtk_drawing_area_new();
gtk_widget_set_size_request(darea, 800, 1200);
gtk_window_set_default_size(GTK_WINDOW(window), 800, 800);
gtk_container_add(GTK_CONTAINER(window), darea);
gtk_widget_set_events(darea, GDK_POINTER_MOTION_MASK);
gtk_widget_show_all(window);
g_signal_connect(darea, "motion_notify_event",
G_CALLBACK (print_event), NULL);
g_signal_connect_swapped(G_OBJECT(window), "destroy",
G_CALLBACK(gtk_main_quit), NULL);
gdkwin = gtk_widget_get_window(darea);
gdk_window_set_event_compression(gdkwin, FALSE);
//gdk_window_set_event_compression(gdkwin, TRUE);
gtk_main();
return 0;
}
stefan@AMD64X2 ~/rth $ ./t
7, 625: 2029540
48, 625: 2029552
89, 623: 2029564
132, 623: 2029576
177, 623: 2029588
222, 621: 2029604
267, 621: 2029616
312, 621: 2029628
357, 621: 2029640
398, 621: 2029652
435, 621: 2029664
476, 621: 2029676
501, 621: 2029688
534, 621: 2029704
563, 619: 2029716
590, 619: 2029728
613, 619: 2029740
636, 617: 2029752
657, 617: 2029764
682, 617: 2029776
701, 619: 2029788
722, 621: 2029804
745, 624: 2029816
770, 622: 2029828
793, 625: 2029840
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
On 2 September 2014 10:15, Stefan Salewski wrote:
> On Mon, 2014-09-01 at 23:29 +0200, ax487 wrote:
>> Just as an illustration: http://picpaste.com/event-DmCNqCHZ.png
>> It does make a difference :)
>
> Yes -- so my assumption was that you get events with better time
> resolution than 10 ms without compression.
>
> So I hacked together a small test in plain C.
> But again, I can not see a difference for my Box.
> (Linux AMD64, Gtk3.12, Gnome3, X11, AMDX2 CPU, nvidia-drivers ...)
>
> Here is the C code and the output, event time delta is general 12 ms
> with few exceptions, no matter if compression is enabled or disabled.
>
> /* http://zetcode.com/tutorials/gtktutorial/firstprograms/ */
> #include
>
> void print_event(GtkWidget *widget, GdkEventMotion *event, gpointer p)
> {
> printf("%.0f, %.0f: %d\n", event->x, event->y, event->time);
> }
>
> int main( int argc, char *argv[])
> {
> GtkWidget *window;
> GdkWindow *gdkwin;
>
> gtk_init(&argc, &argv);
>
> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> gtk_window_set_default_size(GTK_WINDOW(window), 800, 800);
>
> gtk_widget_set_events(window, GDK_POINTER_MOTION_MASK);
>
> gtk_widget_show(window);
>
> g_signal_connect(window, "motion_notify_event",
> G_CALLBACK (print_event), NULL);
>
> g_signal_connect_swapped(G_OBJECT(window), "destroy",
> G_CALLBACK(gtk_main_quit), NULL);
>
> gdkwin = gtk_widget_get_window(window);
>
> // gdk_window_set_event_compression(gdkwin, FALSE);
> gdk_window_set_event_compression(gdkwin, TRUE);
>
> gtk_main();
>
> return 0;
> }
>
> 36, 422: 42037389
> 36, 426: 42037401
> 48, 438: 42037413
> 62, 451: 42037432
> 79, 464: 42037437
> 102, 475: 42037455
> 129, 486: 42037465
> 150, 493: 42037477
> 179, 500: 42037489
> 206, 502: 42037501
> 233, 502: 42037513
> 262, 502: 42037525
> 285, 491: 42037537
> 314, 480: 42037549
> 343, 469: 42037566
> 372, 460: 42037577
> 391, 447: 42037589
> 406, 430: 42037601
> 421, 413: 42037613
> 436, 396: 42037631
> 447, 377: 42037637
>
As stated before, motion events are only *delivered* per frame, all
the compress flag does is set it to deliver the motion as one event
per frame or multiple events per frame. If you have compress true (as
above) only one event is delivered, on each frame time, so thats the
time you see. You only get the position at the end of the frame.
If you turn compress off you will get all the events generated during
the last frame cycle. That allows applications to trace the positions
that the cursor moved through.
Cheers
Lex
>
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
On Mon, 2014-09-01 at 23:29 +0200, ax487 wrote:
> Just as an illustration: http://picpaste.com/event-DmCNqCHZ.png
> It does make a difference :)
Yes -- so my assumption was that you get events with better time
resolution than 10 ms without compression.
So I hacked together a small test in plain C.
But again, I can not see a difference for my Box.
(Linux AMD64, Gtk3.12, Gnome3, X11, AMDX2 CPU, nvidia-drivers ...)
Here is the C code and the output, event time delta is general 12 ms
with few exceptions, no matter if compression is enabled or disabled.
/* http://zetcode.com/tutorials/gtktutorial/firstprograms/ */
#include
void print_event(GtkWidget *widget, GdkEventMotion *event, gpointer p)
{
printf("%.0f, %.0f: %d\n", event->x, event->y, event->time);
}
int main( int argc, char *argv[])
{
GtkWidget *window;
GdkWindow *gdkwin;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size(GTK_WINDOW(window), 800, 800);
gtk_widget_set_events(window, GDK_POINTER_MOTION_MASK);
gtk_widget_show(window);
g_signal_connect(window, "motion_notify_event",
G_CALLBACK (print_event), NULL);
g_signal_connect_swapped(G_OBJECT(window), "destroy",
G_CALLBACK(gtk_main_quit), NULL);
gdkwin = gtk_widget_get_window(window);
// gdk_window_set_event_compression(gdkwin, FALSE);
gdk_window_set_event_compression(gdkwin, TRUE);
gtk_main();
return 0;
}
36, 422: 42037389
36, 426: 42037401
48, 438: 42037413
62, 451: 42037432
79, 464: 42037437
102, 475: 42037455
129, 486: 42037465
150, 493: 42037477
179, 500: 42037489
206, 502: 42037501
233, 502: 42037513
262, 502: 42037525
285, 491: 42037537
314, 480: 42037549
343, 469: 42037566
372, 460: 42037577
391, 447: 42037589
406, 430: 42037601
421, 413: 42037613
436, 396: 42037631
447, 377: 42037637
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
Just as an illustration: http://picpaste.com/event-DmCNqCHZ.png It does make a difference :) On 01.09.2014 18:21, Jasper St. Pierre wrote: > Gtk+ queues up processing motion events until the next tick in the frame > clock. It doesn't matter how fast you draw, we still throttle event > processing to the compositor's redraw cycle. > On Sep 1, 2014 5:57 AM, "Stefan Salewski" wrote: > >> On Mon, 2014-09-01 at 14:12 +0200, ax487 wrote: >>> 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. >> >> Fine when it solves your problems. >> >> From my current understanding it should not! >> >> >> https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression >> >>> Determines whether or not extra unprocessed motion events in the event >>> queue can be discarded. >> >> If your drawing is fast, there should never be unprocessed motion >> events, so event-compression true or false should make no difference. >> >> I have done my tests with Linux, GMOME 3, GTK 3.12, X11, Gentoo AMD64 >> box, and was not able to see an effect. Maybe with other configuration >> there is an effect. Some years ago I did some testing with the >> MOTION_HINT_MASK and also saw no effect, and googling gave me some post >> of others having problems with the hint mask also... >> >> But not a big problem for me currently, generally I get motion events at >> least every 12 to 17ms, which is OK, I really think with a 60 Hz Display >> there is no way to get more smooth movements. (Indeed I wonder if there >> is a way to sync movement with display refresh rate. My guess is that >> double buffering and 60 Hz screen refresh will ad more delay to the 12 >> ms event interval, which may result in not really smooth movements >> sometimes.) >> >> >> ___ >> gtk-list mailing list >> gtk-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-list >> > ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
Gtk+ queues up processing motion events until the next tick in the frame clock. It doesn't matter how fast you draw, we still throttle event processing to the compositor's redraw cycle. On Sep 1, 2014 5:57 AM, "Stefan Salewski" wrote: > On Mon, 2014-09-01 at 14:12 +0200, ax487 wrote: > > 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. > > Fine when it solves your problems. > > From my current understanding it should not! > > > https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression > > >Determines whether or not extra unprocessed motion events in the event > >queue can be discarded. > > If your drawing is fast, there should never be unprocessed motion > events, so event-compression true or false should make no difference. > > I have done my tests with Linux, GMOME 3, GTK 3.12, X11, Gentoo AMD64 > box, and was not able to see an effect. Maybe with other configuration > there is an effect. Some years ago I did some testing with the > MOTION_HINT_MASK and also saw no effect, and googling gave me some post > of others having problems with the hint mask also... > > But not a big problem for me currently, generally I get motion events at > least every 12 to 17ms, which is OK, I really think with a 60 Hz Display > there is no way to get more smooth movements. (Indeed I wonder if there > is a way to sync movement with display refresh rate. My guess is that > double buffering and 60 Hz screen refresh will ad more delay to the 12 > ms event interval, which may result in not really smooth movements > sometimes.) > > > ___ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
On Mon, 2014-09-01 at 14:12 +0200, ax487 wrote: > 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. Fine when it solves your problems. >From my current understanding it should not! https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression >Determines whether or not extra unprocessed motion events in the event >queue can be discarded. If your drawing is fast, there should never be unprocessed motion events, so event-compression true or false should make no difference. I have done my tests with Linux, GMOME 3, GTK 3.12, X11, Gentoo AMD64 box, and was not able to see an effect. Maybe with other configuration there is an effect. Some years ago I did some testing with the MOTION_HINT_MASK and also saw no effect, and googling gave me some post of others having problems with the hint mask also... But not a big problem for me currently, generally I get motion events at least every 12 to 17ms, which is OK, I really think with a 60 Hz Display there is no way to get more smooth movements. (Indeed I wonder if there is a way to sync movement with display refresh rate. My guess is that double buffering and 60 Hz screen refresh will ad more delay to the 12 ms event interval, which may result in not really smooth movements sometimes.) ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
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 ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
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
Re: Accuracy of motion events
On Sat, 2014-08-30 at 02:18 +0200, Stefan Salewski wrote:
> Sounds great, thanks. Can not test with Ruby currently, it is 3.12,
> which is not available yet for Ruby bindings.
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.
stefan@AMD64X2 ~/fups $ ./test
34 299
81 297
130 297
181 297
232 297
281 299
328 299
375 299
422 299
467 302
510 304
549 304
588 307
623 309
660 311
import gtk3, gdk3, glib2, math
proc destroy(widget: pWidget, data: pgpointer) {.cdecl.} = main_quit()
proc process_event(widget: pWidget, event: TEventMotion, data:
pgpointer) {.cdecl.} =
echo round(event.x), " ", round(event.y)
var window = window_new()
window.set_default_size(800, 800)
discard g_signal_connect(window, "destroy", G_CALLBACK(test.destroy),
nil)
discard g_signal_connect(window, "motion_notify_event",
G_CALLBACK(test.process_event), nil)
window.show_all
window.get_window.set_event_compression(gfalse)
window.get_window.set_events(TEventMask.POINTER_MOTION_MASK)
main()
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
On Sat, 2014-08-30 at 00:39 +0100, Emmanuele Bassi wrote: > motion events (and touch update events) are compressed on a per-frame > basis, since it the correct thing to do for every class of > applications *save* for drawing ones. for those, we have API to > disable event compression on a per-GDK window basis: > > https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression > > your application should benefit from this API. Sounds great, thanks. Can not test with Ruby currently, it is 3.12, which is not available yet for Ruby bindings. Stefan Salewski ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
On Fri, 2014-08-29 at 16:58 -0500, richard boaz wrote:
> you can find a discussion and one possible solution of this in a previous
> thread:
>
> https://mail.gnome.org/archives/gtk-list/2011-July/msg00059.html
I think unfortunately the solution is not that easy...
I have a similar problem with my CAD tool
(http://www.ssalewski.de/PetEd.html.en) -- for fast object movements
moving is not as smooth as it could be. First I thought that simple my
drawing speed is still too slow, but after some optimizations that is
not the problem any more. Indeed it is not a big problem for me, and I
was busy with other tasks, so I have not spent time investigating it.
But I found same reports of other people with similar or related
problems
(http://stackoverflow.com/questions/16359775/gtk-motion-notify-event-is-hint-always-true)
As the author of this question did not provided a minimal test, I just
hacked together this code below. Well it is Ruby, but I would be
surprised if result is much better for plain C. When I move the mouse
pointer fast from left to right, I get the output below, with large gaps
in x coordinate. So I guess that the rate of motion notify events is
indeed low. (I know that there is a POINTER_MOTION_HINT_MASK available,
to suppress too high rates, but that should not help...)
My feeling is, that the maximum event rate is hard coded in GDK library,
I think I read that years ago. Would be not really nice...
stefan@AMD64X2 ~ $ ruby test.rb
4 481
20 481
37 481
57 481
70 481
87 483
104 483
120 483
140 483
160 483
181 483
207 481
226 481
require 'gtk3'
window = Gtk::Window.new
window.set_default_size(800, 800)
window.signal_connect("destroy") {Gtk.main_quit}
window.add_events(Gdk::Event::Mask::POINTER_MOTION_MASK)
window.signal_connect("motion_notify-event") {|w, e|
print e.x.round, " ", e.y.round, "\n"
}
window.show_all
Gtk.main
>
> On Fri, Aug 29, 2014 at 4:29 PM, ax487 wrote:
>
> > Hello all,
> >
> > I am wondering about the rate at which pointer motion events are
> > generated. In my application I draw strokes on a canvas. I noticed that
> > if I move the pointer at a high velocity the strokes no longer appear as
> > smooth as for slower pointer motions. The time between motion events (>=
> > 10ms) seems to be inadequate to capture the motion correctly. Is there
> > anyway to increase the time accuracy?
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
hi; On 29 August 2014 22:29, ax487 wrote: > I am wondering about the rate at which pointer motion events are > generated. In my application I draw strokes on a canvas. I noticed that > if I move the pointer at a high velocity the strokes no longer appear as > smooth as for slower pointer motions. The time between motion events (>= > 10ms) seems to be inadequate to capture the motion correctly. Is there > anyway to increase the time accuracy? motion events (and touch update events) are compressed on a per-frame basis, since it the correct thing to do for every class of applications *save* for drawing ones. for those, we have API to disable event compression on a per-GDK window basis: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression your application should benefit from this API. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Accuracy of motion events
you can find a discussion and one possible solution of this in a previous thread: https://mail.gnome.org/archives/gtk-list/2011-July/msg00059.html r- On Fri, Aug 29, 2014 at 4:29 PM, ax487 wrote: > Hello all, > > I am wondering about the rate at which pointer motion events are > generated. In my application I draw strokes on a canvas. I noticed that > if I move the pointer at a high velocity the strokes no longer appear as > smooth as for slower pointer motions. The time between motion events (>= > 10ms) seems to be inadequate to capture the motion correctly. Is there > anyway to increase the time accuracy? > > ax487 > ___ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
