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@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
