Re: Accuracy of motion events

[Stefan Salewski <mail ssalewski de>]

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.)