Path: utzoo!utgpu!watmath!iuvax!purdue!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: UWM network use followup
Message-ID: <1253@bacchus.dec.com>
Date: 20 Mar 89 17:41:37 GMT
References: <890032@hpfcdq.HP.COM> <8903200443.AA21539@jumbo.pa.dec.com>
Organization: DEC Western Software Lab
Lines: 33

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