[_CDCSL_93-16_]<1>Cedar>release>SlackProcess>SlackProcessDoc.tioga

SlackProcessDoc.tioga

Ken Pier and Eric Bier, March 14, 1991 1:10 pm PST

Christian Jacobi, October 2, 1992 11:54 am PDT

Slack Process

CEDAR 10.1 —

Slack Process

Eric Bier and Ken Pier

Abstract: SlackProcess solves a problem in user interfaces that employ smooth motion. User input actions (e.g. from a TIP table) are placed on a queue. The slack process takes these actions from the queue, doing as many as it can. When the slack process gets behind, it ignores some actions to catch up. The client indicates which actions can be ignored using a callback procedure. SlackProcess can be used in place of MBQueues to provide sequentialization as well to take up slack during smooth motions.

Created by: Eric Bier

Maintained by: Bier.PA, Pier.PA

Keywords: Cedar, queue, input

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

Changes Log:

Christian Jacobi: October 2, 1992

Made it independent of Viewers. Sorry that the interface mentions ViewerClasses. I was not able to recompile the interface, but, the viewer arguments are not really used. It really can now also be used with XTk.

1. SlackProcess

SlackProcess solves a problem in user interfaces that employ smooth motion. For instance, in Gargoyle and Solidviews, the user can move objects smoothly by moving the mouse. Problem: how often should the frames be redrawn? The easiest solution to implement is to redraw the scene once for each mouse motion action from the TIP table. Unfortunately, for complex frames, this results in the redrawing getting behind the user. A simple improvement, suggested years ago by Scott McGregor, is to queue up the TIP table actions, and provide a second process, the slack process, to dequeue and execute them. If the slack process gets behind, it drops some actions on the floor in order to catch up. Thus the motion is "as smooth as possible" but doesn't get behind. Scott points out that, as more processing power becomes available, this algorithm allows motion to get smoother without recoding.

The name SlackProcess refers to the user's perception, with the naive algorithm, that the objects he is dragging are lagging farther and farther from the cursor, like a dog with too long a leash.

SlackProcess also serves to synchronize user actions. There is no need to use MBQueues and similar packages if SlackProcess is used.

Multiple slack processes and their associated queues may be used by many clients; the slack process issues a handle containing MONITORED data for use by the client. Actions may be queued by calls to QueueAction or QueueAtHead. The queueing routines now take a Process.Priority specifying the priority to use while executing each action. The routine QueueIsBusy allows a caller to see if the slack process is doing something; this can be useful if you wish to make sure that you are the only thread running in a certain body of code.

Each SlackProcess provides a logging feature for clients. A client can register a Logging procedure and enable/disable Session logging. With logging enabled, the registered Logging procedure will be called every time an action is dequeued. The client may then save a log or script of the session in progress for later playback to a future SlackProcess.

Each SlackProcess provides an abort feature for clients. [Note: Abort does not work yet in PCedar (March 13, 1991).] A client can register an Abort procedure and some abort data and enable/disable aborting. With aborting enabled, the slack queue will be flushed and the registered abort procedure will be called (with the abort data as argument) every time an abort occurs. The current trigger for the abort action is holding down SHIFT-SWAT with the cursor in the viewer to be aborted. If the viewer specified when aborting is registered is NIL, then the cursor position will be ignored when checking for abort.