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
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
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
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 m...@ssalewski.de wrote:
On Mon, 2014-09-01 at 14:12 +0200, ax487
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
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.
On 2 September 2014 10:15, Stefan Salewski m...@ssalewski.de 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
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 (=
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 ax...@gmx.de wrote:
Hello all,
I am wondering about the rate at which pointer motion events are
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
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
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
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
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
14 matches
Mail list logo
