Re: [gtk-list] Re: Does gtk+ support motion compression?

[Robert Minsk <egbert centropolisfx com>]

Havoc Pennington wrote:
> 
> Robert Minsk <egbert@centropolisfx.com> writes:
> > Does gtk+ support motion compression like the Xt compress_motion field in a
> > widget?  Looking thru the src it only seems to support exposure compression.
> > Would it be very hard to add motion compression to the event loop?
> >
> 
> Use the  see my book or the scribble example
> in the GTK tutorial.
> 
> Havoc
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null

  Reading thru the appropriate chapters last night in your book I
really think motion compression can be an added benefit to gtk+.  In
the book you talk about when using the POINTER_MOTION_HINT_MASK to
call gdk_window_get_pointer to get the pointer position.  The code
for gdk_window_get_pointer causes a round trip to the server.  This
is slow and can cause a more subtle bug.  By calling
gdk_window_get_pointer the application is going around the event
queue.  The next event on the queue could be something important to
my widget.  The mouse could have moved between the time the event was
put on the queue and the application calls gdk_window_get_pointer.
Motion compression will deliver the events "in order".

  Using a scroll bar as an example.  The user pushes the mouse
button on the scroll bar making it "active".  While the application
is busy the user releases the mouse button but continues to move the
mouse.  My application then calls gdk_window_get_pointer and gets the
mouse position and decides to redraw.  Notice this is not the
position where the user released the mouse but the current position.
Then the application receives the release event.  Looking at the
position in the button release event we have to redraw again.  A
sort of backing up.  Not really a bug, but it could cause the scroll
region to "pop".

  Looking at the event dispatching in gtk_main_do_event motion
compression does not seem that hard to implement.  Heck, it's already
compressing enter/leave events.  The main difference is it would
have to check the widget to see if it wants motion compression.
The next line after enter/leave compression is looking up the widget.
So thats pretty much done.  You can pretty much rip off the compression
code from the Xt tree.  Also there are plenty of bits left in the
GdkEventMask.

  The hard part, if you decide to implement it, is to go back and
change the old widgets to use motion compression instead of
explicitly getting the mouse position where applicable.  Second is
the documentation.  Allot people are going to use the book for
documentation which was published before this could be a feature.
That's what release notes are for ;-)

  I'm sorry I forgot to follow up to the list with this discussion.
If you want, I can summarize our discussion to the list.