The Camel and his confounded Ball

During any prolonged 'mouse-down' situation (for instance 
button-tracking or auto-scrolling in a list) the Arrow cursor changes 
after a second or so into the Camel and his Ball.

What happens is variable; sometimes the change from Arrow to 
Camel+Ball is almost instantaneous; sometimes it takes several 
seconds; sometimes it doesn't happen at all. Does anybody know what 
really goes on under the hood?

It is usually possible to slip in an "InitCursor" call in the 
mouse-down loop. This resets the cursor back to the Arrow but at the 
cost of an irritating flicker. A good example of this is the 
'Navigation.pm' window in which the flicker between Arrow and 
Camel+Ball is incessant: unacceptably so IMHO. I suspect 'InitCursor' 
calls might be the cause?

For instance in a MacList you might have a loop of the kind:

     if ($select) {         # i.e.if the cell is 'selected'
         #InitCursor;
         if ($CurrentEvent and $CurrentEvent->what == 1) {WaitNextEvent}
         &redraw_selected_cell
     }

The change from Arrow to Camel+Ball can be reversed by the call to 
'InitCursor' or alternatively by calling 'WaitNextEvent' if the mouse 
is down (i.e. $CurrentEvent->what == 1). Strangely that works with no 
'flicker' but at the cost of severely slowing up the execution. As a 
method it is reasonably satisfactory for button-tracking (where the 
delay barely shows up) but certainly not satisfactory in a list 
context (where the delay is painfully apparent).

Does anyone know >why< calling 'WaitNextEvent' should suppress the 
change from Arrow to Camel+Ball? Is there any other way of preventing 
the nuisance; some way of kicking the confounded ball into touch for 
the duration of a script? Do we really need the Camel+Ball anyway?

Alan Fry