Path: utzoo!attcan!uunet!pyrdc!grebyn!umd5!jonnyg
From: jonnyg@umd5.umd.edu (Jon Greenblatt)
Newsgroups: comp.windows.x
Subject: Re: xset m accl. theres. and XNextEvent (MotionNotify)
Message-ID: <2865@umd5.umd.edu>
Date: 30 Jun 88 14:45:28 GMT
References: <8806291927.AA15530@gilroy.dec.com>
Reply-To: jonnyg@umd5 (Jon Greenblatt)
Organization: University of Maryland, College Park
Lines: 67

In article <8806291927.AA15530@gilroy.dec.com> haynes@WSL.DEC.COM writes:
>
>	Huh, it seems to me the server does mouse compression for you.
>
>Wrong. When the server sees the mouse device move, it sends out a mouse
>motion event. It (normally) has no way of knowing if the client is
>ready for that mouse event yet, or whether it's just adding another
>event to the client's input queue.
>
>	Having the client do it is stupid.
>
>Wrong. It is sometimes, maybe usually stupid, but not always. With a
>slow client and a fast server the server could easily swamp the client
>with mouse motion events. Only the client is in a position to decide if
>it is "stupid" to compress.
>
>	Every windowing system I have used does this by default
>
>Congratulations. Do you use X? If so, wrong again. There are two queues
>here, the mouse device driver queue, and the client input queue. The
>server can, and does, compress the mouse device driver queue, but it
>has no way of compressing the client input queue. That must be done on
>the client side, and that's what I was talking about.
>
>	read the manual carefuly.
>
>	"The bookful blockhead, ignorantly read,
>	With loads of learned lumber in his head."
>
>		-- Alexander Pope, "An Essay on Criticism"
>
>	-- Charles


	Ok, I read the manual myself and found a way to compress events on the
server side. 

1: Create a seperate process to wait for mouse motion events.

2: On recipt of a mouse moved event do a XSync then do a query pointer to
   get the current mouse location.

3: Put this event back on the queue for the application, I seem to remeber
   that pushed back events have the high bit set so it can be searched for
   seperately.

4: The seperate process is not needed if the only thing you are looking for
   is motion events.

	I could not seem to find another way of doing this. It seems to me
collecting all the mouse moved events would take a lot of net I/O. This
is why I say not having the "option" to compress events is stupid. Micro-
soft products seem to do this by default, it seems to save a lot of processing
time. Maybe in X this is not a serious problem but I have been using this
feature a lot the last couple of weeks in MS-Windows.

If I am right that there is not a way to compress events on the server side
than I feel the X implementers should consider including one. Having it as
a default may not be necessary but it should be an option. Oh yea MS-Windows
works using only compressed mouse events, I could see how that would be a 
problem with a drawing type application.

	I seem to remeber a XCompressEvents in X10, somone correct me if I
am wrong.

						JonnyG.
						jonnyg@rover.umd.edu