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 — FOR INTERNAL XEROX USE ONLY
Slack Process
Eric Bier and Ken Pier
© Copyright 1986 Xerox Corporation. All rights reserved.
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
For Internal Xerox Use Only
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.