barmar@think.COM (Barry Margolin) (03/16/89)
A couple of days ago I posted a question about the high volume of
network use UWM uses when it puts up its positioning corner for a new
window. The only response I received was a suggestion to look at the
output of xscope. I've done that now. It answers the "what is it
doing" question, but doesn't explain why. Apparently it's repeatedly
sending PolyLine and QueryPointer requests, and the server is
responding with QueryPointer replies. My guess is that it's manually
tracking the cursor and drawing the positioning corner. Why is it
doing this itself, instead of letting the server do it?
Barry Margolin
Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarjim@EXPO.LCS.MIT.EDU (Jim Fulton) (03/16/89)
Uwm displays a box as the initial tracking element, so it has to draw it itself. It used QueryPointer loops to get the fastest interaction.
toml@hpfcdq.HP.COM (Tom LaStrange) (03/19/89)
>A couple of days ago I posted a question about the high volume of >network use UWM uses when it puts up its positioning corner for a new >window. The only response I received was a suggestion to look at the >output of xscope. I've done that now. It answers the "what is it >doing" question, but doesn't explain why. Apparently it's repeatedly >sending PolyLine and QueryPointer requests, and the server is >responding with QueryPointer replies. My guess is that it's manually >tracking the cursor and drawing the positioning corner. Why is it >doing this itself, instead of letting the server do it? > >Barry Margolin >Thinking Machines Corp. If uwm were to wait for MotionNotify events, you would see window move and resize operations slow to a crawl. You'll see the same QueryPointer scheme in twm. -- Tom LaStrange Hewlett Packard Co. ARPA: toml%hpfcla@hplabs.hp.com Graphics Technology Division UUCP: hplabs!hpfcla!toml Fort Collins, CO
msm@SRC.DEC.COM (Mark S. Manasse) (03/20/89)
> If uwm were to wait for MotionNotify events, you would see window move > and resize operations slow to a crawl. You'll see the same QueryPointer > scheme in twm. How some people will torture other users of shared resources, just to improve performance by a sixtieth of a second.... "Slowed to a crawl" is quite an overstatement. The current servers give event dispatching high priority, so you get your event just about as quickly as you get the response to your QueryPointer; event dispatching is more complicated than request processing, but not much. The overhead in Xlib is somewhat higher for events than for responses, but we're only talking tens of microseconds. The real problem is that if you use MotionNotify events you're likely to either fall behind the server or have the server fall behind you. You must 1) do event compression on the client side, and do some synchronizing action periodically in case the painting operations you're issuing are too difficult for the server to keep up with, or 2) use PointerMotionHint. Detailed analysis: while the mouse is moving, the server will generate an event for you once every screen refresh or so. If the processing time for a motion event takes longer than that, a large queue of events will build up behind the window manager. This will result in feedback which is tracking places where the mouse used to be. By discarding all MotionNotify events which are immediately followed by another MotionNotify for the same window, you can remedy this. Unfortunately, that's not good enough: the painting operations your window manager generates to produce feedback may be very inexpensive, but the server processing time to execute them may be large. Then the event compression won't help any: the window manager can keep up with server events. But the queue of painting requests between the window manager and the server will grow and grow, causing the same appearance as before. We can solve this by forcing some synchronizing operation to take place periodically; XQueryPointer happens to work for that, but XSync would work as well. Using PointerMotionHint solves all the synchronization problems, but it does cost you a little in performance. Mark
asente@decwrl.dec.com (Paul Asente) (03/21/89)
In article <8903200443.AA21539@jumbo.pa.dec.com> msm@SRC.DEC.COM (Mark S. Manasse) writes: > >> If uwm were to wait for MotionNotify events, you would see window move >> and resize operations slow to a crawl. You'll see the same QueryPointer >> scheme in twm. > >How some people will torture other users of shared resources, just >to improve performance by a sixtieth of a second.... > >"Slowed to a crawl" is quite an overstatement. Not really. I did some extensive performance analysis on this last year and got the following results: 1) As long as the user keeps moving the pointer, the amount of compute resources and net activity is roughly the same no matter whether you're being driven by pointer motion or by a polling loop. If the pointer stops moving, of course, the polling loop continues to use the same amount of resources while pointer motion uses none. 2) No matter how cleverly I programmed it, I was unable to make using pointer motion react as crisply as polling, especially across a network. If you have to do much processing on the client side, being motion driven does "slow to a crawl". 3) The pointer motion hint stuff in the protocol, while an admirable effort, is actually rather useless. The two round trips forced by the protocol slow things down too much. I'll try to dig up my actual figures and post them. -paul asente asente@decwrl.dec.com decwrl!asente
colas@mirsa.inria.fr (Colas NAHABOO) (03/21/89)
From article <8903200443.AA21539@jumbo.pa.dec.com>, by msm@SRC.DEC.COM (Mark S. Manasse): > >> If uwm were to wait for MotionNotify events, you would see window move >> and resize operations slow to a crawl. You'll see the same QueryPointer >> scheme in twm. > > How some people will torture other users of shared resources, just > to improve performance by a sixtieth of a second.... No! I back up entirely Tom, using MotionNotify events is IMPOSSIBLE for dragging operation. It might work locally on your machine, with a client/server connection via shared memory, but will crawl via the network. Moreover, it's the USER that you are torturing if you cannot provide him with immediate feedback. Better torture your application code! PS: on my first try, using MotionNotify in GWM resulted in very funny effects, but it was in no way usable. Colas NAHABOO -- colas@mirsa.inria.fr BULL Research FRANCE -- Koala Project -- GWM X11 Window Manager
kmtaylor@hplabsz.HPL.HP.COM (Keith M Taylor) (03/22/89)
In article <8903200443.AA21539@jumbo.pa.dec.com> msm@SRC.DEC.COM (Mark S. Manasse) writes: > ... > >Using PointerMotionHint solves all the synchronization problems, >but it does cost you a little in performance. > Maybe I don't understand PointerMotionHint. It seems to me that granularity is too coarse. You only get a MotionNotify when some other (button, key, leave window) event occurs. If you want to do drawing that tracks the cursor, you're back to polling. Keith M. Taylor
jta@bilbo.locus (Jim Anderson) (03/22/89)
At this risk of getting burned to a cinder, I think a few points are being missed in this discussion. First, uwm or any other window manager that is moving a frame around on the display is drawing into the root window using a not-clipped-by-children GC. When you do this you gotta grab the server from the time you draw the frame until you erase it or you might leave tracks in somebody's window. Uwm is trying to be a semi-nice client, so as fast as he can he is grabbing the server, drawing the frame, erasing the frame and ungrabbing the server. This shows a flashing frame, but lets other clients draw on the screen. Uwm has a freeze/nofreeze option in the .uwmrc file that controls whether it does this, or just grabs the server for the duration, but it seems to ignore the setting of this option for the initial window placement. Try setting this option either way and notice the difference on a window move. Second, a combination of PointerMotionHints and QueryPointer is the way to go. QueryPointer resets the PointerMotionHint filter, so this works quite well. Using PointerMotion events seems to work ok too, as long as you eat multiple events without redrawing the frame for each. I'll bet someone will correct me if I'm wrong about any of this.