Since RightSpeed has not been released, no application currently exists that explicitly communicates its task information to RightSpeed. Furthermore, even when it is released, we expect few application writers will be both willing and able to communicate such information. Therefore, for RightSpeed to be useful, we require an automatic task detector to infer task information from such applications and to call the task specification interface on their behalf.
Our approach focuses on the tasks the user cares about most: those triggered by user interface events. User interface studies have shown that response times under 50-100 ms do not affect user think time [20]; we thus consider 50 ms the soft deadline for handling a user interface event. An exception is mouse movements, whose tracking may require response times of only 25-50 ms [13]; we thus consider 25 ms the soft deadline for handling them.
We consider a task to begin when an application receives a user interface event. We classify tasks into types, and deduce the task type from the event characteristics, i.e., whether it is a keystroke, mouse movement, or mouse click; which key or mouse button was pressed or released; and to what application the event was delivered. As shown in [12], separating tasks into types this way makes estimation of task work distribution more accurate, and enables us to set different policies for, for instance, keystrokes and mouse clicks.
As suggested in [12], we use the minimum speed available
as the pre-deadline speed for mouse movement events. Such events
require little processing, so this is sufficient to meet practically
all task deadlines. We use a default pre-deadline speed of 
for keystroke events and 
for mouse click events, where 
is
the maximum speed available on the machine. A better approach might
be to compute a variable pre-deadline speed based on the distribution
observed and the likelihood of missing deadlines at various
pre-deadline speeds, as suggested in [12].
Unfortunately, this requires accurate estimation of the tails of
nonstationary distributions, and we do not yet know how to do this;
this is future work.
We also need a heuristic to determine when such an inferred task is complete, since it is difficult to determine what CPU activity belongs to a given task. We use the heuristic from [12] described in Section 2.4: we consider a task complete when either (a) all threads in the system above the idle priority level are blocked and no I/O is ongoing, or (b) another user interface event is delivered to the same application. An advantageous side effect of this is that time spent by unrelated threads is considered part of the task. Thus, the speed schedule chosen will automatically account for the work performed by other threads during the task. Without this accounting, the presence of such unrelated activity could interfere with RightSpeed meeting its target deadlines.