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