Input and games.

[Bill Spitzak]

Todd Showalter wrote:

>     Decelerate/accelerate would cover all the cases I can think of.

I thought you said the speed of mouse movement controlled whether it 
slowed down or not. Ie if the user quickly dragged the slider to the 
bottom then the scrollbar was at the bottom, but if they moved slowly 
then it moved by lines. So it is not just "slow the mouse down" but 
"slow the mouse down only if it is being moved this speed".

For the proposed scrollbar the amount of deceleration depends on the 
document size, so the client has to control it. And an extremely large 
document is going to give you problems by making the mouse movements 
approach the fixed point fraction size. If this is avoided by returning 
the mouse movements in full-size pieces like the pointer-lock does then 
they have to be marked as to whether they are decelerated or not.

If the threshold between fast/slow is going to be built into the server, 
I really recommend some other annoying things be built into the server 
such as decisions about whether something is double-click and whether 
the user holding the mouse down and moving it a bit is "clicking" or 
"dragging", and at what point the user not holding the mouse down but 
moving it tiny bits is "hovering". Inconsistency between applications in 
these is incredibly annoying to the user.

The server is also going to have to pointer-warp back the cursor when it 
receives the decelerate request, and serial numbers have to be used so 
the client can ignore the pre-decelerate mouse movements.

All in all I see this as being enormously more complex than pointer warp.