Re: Where to implement motion compression

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 22 Feb 2000, Owen Taylor wrote:
> 
> > 
> > Robert Minsk <egbert@centropolisfx.com> writes:
> > 
> > > I currently adding motion compression to the event loop in gtk+ and wanted
> > > some feedback as to what library (gdk or gtk) to implement it.  Motion
> > > compression filter throws out all but the last motion notify (the most
> > > recent position).  This is useful for widgets that need the most up-to-date
> > > position but do not need the full history of pointer positions.  Unlike the
> > > current MOTION_HINT_MASK this would be done in the event loop avoiding the
> > > round trip to the X server with gdk_window_get_pointer.  Also events are
> > > delivered in order (see discussion on gtk-list).
> 
> the point in calling gdk_window_get_pointer() is not actually to get a more
> accurate position, but to trigger the next motion hint.
> 
> > > I currently have implemented it in gtk_main_do_event and have added a
> > > GtkWidgetFlag called GTK_COMPRESS_MOTION.  This seems like the correct
> > > place to add it because it is a property of the widget.
> > > 
> > > It could be implemented more efficiently in gdk_event_translate and make it
> > > a property of the window.  I would add GDK_POINTER_MOTION_COMPRESS_MASK to
> > > GdkEventMask but that does not make since because it is not an event.
> > > There's the problem.
> > 
> > I like this better. Yes, it is not an event, but it closely
> > parallels GDK_MOTION_HINT_MASK as a property of how events
> > are handled for a particular window. (Also, this would give
> > a natural way of handling compression for pointer grabs
> > if we wanted to add this later.)
> > 
> > The user doesn't need to know that GDK_MOTION_HINT_MASK is
> > handled on the server and GDK_MOTION_COMPRESS_MASK is
> > handled in the client.
> > 
> > The way to implement this then, is to add flag to the private
> > data structure for GdkWindow that is updated from 
> > gdk_window_new and gdk_window_set_evnets.
> 
> the way i understand things, it only makes sense to compress subsequent
> motion events. so then what's the problem with simply discarding the
> current motion notify event (unconditionally) if the next one in the
> queue is a motion notify event for the same window?

Typically you don't have straight motion events - but rather
motion events intermixed with exposes and configure notifies. 

For motion events, it's fine to compress across basically anything 
but button presses and releases, and DestroyNotify events.
(This is different from the situation for expose events.)

The reason you don't always want to compress is that some applications - 
say a painting program - actually want the full event sequence.

Regards,
                                        Owen