haynes@WSL.DEC.COM (06/28/88)
Use pointer motion hints to avoid swamping your server. Use mouse compression to avoid swamping your application. Re-write the server to really fix the problem. -- Charles
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/29/88)
Date: 27 Jun 88 17:22:46 GMT
From: tikal!ole!powell@beaver.cs.washington.edu (Gary Powell)
Q: When I do a resize of a window I first get a Expose event then a Configure
event. shouldn't I only get the Configure event.
You don't say which window manager you are using. For example, uwm tends to
place this little resize box over your window, and when uwm unmaps it you
will get an Expose event. If you are using a reparenting window manager,
then you get an "extraneous" Expose event when the window manager frame
is resized; this is a known deficiency in the MIT servers.
After resizing process..(I re-paint the window) I get an Expose event again.
Right. That's the real Expose event.
I did try setting the CWBackingStore flag and my server ignored it.
Right. Again, known deficiency in the MIT servers.
The window manager must be doing the save for moving of the window
The server does this.
Q: When I Create a window I get an Expose and a Configure event. I check the
the relative size and it of course hasn't changed so I don't do a re-size.
But I shouldn't need an Expose event after all I just got thru painting the
stuff into the window. (I'm not overlapped at any time.)
You don't know that you won't be overlapped at any time. You should be
repainting on Expose events, not on Configure or Map events. You should
use Configure events simply to cache size information and adjust internal
databases.jonnyg@oracle (Jon Greenblatt) (06/29/88)
>Hi Dan, > >Sorry about the terseness of my message, I didn't know what degree of >expertise to aim the reply at. Here's an amplification. > >Pointer motion hints is something you can turn on that affects the >delivery of mouse motion events. What setting it does is tell the >server to send you one mouse motion event (the "hint") any time the >mouse moves, but after sending that one mouse motion event, it will >wait for an ack from you before sending any more. You send the ack by >doing a QueryPointer or by doing an AllowEvents (?) which causes the >server to go back to the state where it's looking at mouse motion and >ready to send you a hint. This lets you use an event driven model for >the program, but still synchronize with the server. ... >Mouse compression is a client side technique, only useful if your >*client* is falling behind in processing incoming mouse events. It's >what Xlib did in X10, when you get an incoming mouse event, you peek at >the event queue to see if the next event is a mouse motion event for >the same window. If it is you throw away the current one and iterate. >The toolkit uses this technique when a widget asks for "mouse >compression". It turns out to not be as useful as you might imagine, >since most applications can actually process mouse motion fairly >quickly (as you've discovered.) ... Huh, it seems to me the server does mouse compression for you. Having the client do it is stupid. Every windowing system I have used does this by default, read the manual carefuly. JonnyG.
haynes@WSL.DEC.COM (06/29/88)
Hi Dan, Sorry about the terseness of my message, I didn't know what degree of expertise to aim the reply at. Here's an amplification. Pointer motion hints is something you can turn on that affects the delivery of mouse motion events. What setting it does is tell the server to send you one mouse motion event (the "hint") any time the mouse moves, but after sending that one mouse motion event, it will wait for an ack from you before sending any more. You send the ack by doing a QueryPointer or by doing an AllowEvents (?) which causes the server to go back to the state where it's looking at mouse motion and ready to send you a hint. This lets you use an event driven model for the program, but still synchronize with the server. One of the problems many X servers have is that they assign higer priority to servicing outgoing device events than to processing incoming X requests. What happens is that the user moves the mouse, the server sends out a mouse motion event, which causes the application to send a certain number of output requests to the server, and the server can't process all of them before the next mouse motion event. It gradually gets farther and father behind, eventually dieing in some more or less obscure way. Pointer motion hints causes it to do your painting requests before looking for more mouse motion, since it isn't sending out mouse events until it sees your QueryPointer, which will presumably be after all of you painting requests. Another alternative is to sit in a loop doing QueryPointer and processing the current mouse position. This has the advantage that your input side and output side stay synched, but has two disadvantages: 1) it creates a fixed load on the server and your application, even when the mouse isn't moving, and 2) it makes it tricky to handle the other incoming X events (you need to do some sort of simple timesharing and scheduler). Unfortunately doing a QueryPointer loop in a toolkit application is hard. The last alternative is to make your server fast enough, or smart enough, to not "get behind". There are various techniques including scheduling I/O more "fairly", packetizing output, timeslicing, etc. This is what I meant by "fix the server". Mouse compression is a client side technique, only useful if your *client* is falling behind in processing incoming mouse events. It's what Xlib did in X10, when you get an incoming mouse event, you peek at the event queue to see if the next event is a mouse motion event for the same window. If it is you throw away the current one and iterate. The toolkit uses this technique when a widget asks for "mouse compression". It turns out to not be as useful as you might imagine, since most applications can actually process mouse motion fairly quickly (as you've discovered.) Doing a XSync after completing your output requests, but before asking for the next mouse event should work, but would be slow. Pointer motion hints should acheive the same effect with better performance. Doing good mouse tracking is one of the trickier areas of using X. -- Charles P.S. I'm speculating that the obscure server errors you're seeing are a result of input buffer overruns due to being so far behind.
haynes@WSL.DEC.COM (06/30/88)
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
jonnyg@umd5.umd.edu (Jon Greenblatt) (06/30/88)
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
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/30/88)
Most people believe mouse compression should be done in the server. Doing this "right" probably requires kernel support (the X motion history buffer should probably be maintained in the kernel), but we have no control over device drivers. The current server internals assume that the ddx layer (somehow) compresses events, but most currently do not (at least not as we shipped in R2). XCompressEvents in X10 was only on the client side; the motion hint stuff in the X11 protocol was designed as an improvement.