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