Re: Accuracy of motion events

[ax487 <ax487 gmx de>]

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" <mail ssalewski de> 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