[99] in java-interest
Input "meltdown" in AWT
daemon@ATHENA.MIT.EDU (Scott Hudson)
Fri May 19 14:11:40 1995
From: hudson@cc.gatech.edu (Scott Hudson)
To: java-interest@java.Eng.Sun.COM
Date: Fri, 19 May 1995 11:35:43 -0400 (EDT)
It appears that input and output processing are unbalanced in AWT, in an
important and unfortunate way. Specifically,
inputs are given absolute priority over redraws. This
means that if there is a steady stream of inputs (e.g., mouse movement
events) they can completely block out screen updates. In particular,
if the computation needed to respond to a mouse movement takes longer
than the delivery interval for the next mouse movement event, then no
screen update occurs. In the case of of a dragging interaction, this
means that no feedback is visible to the user. This effectively
precludes dragging as a viable interaction technique whenever there is
even moderate computational load involved with the drag.
A page with an Applet that demonstrates this can be found at:
http://www.cc.gatech.edu/gvu/people/Faculty/hudson/hotjava/drag.html
The problem seems to lie in the fact that the updater thread spawned
in awt.DisplayItemWindow.startUpdater() gives itself a priority of
NORM_PRIORITY-1 (at awt/DisplayItemWindow.java:536), whereas input is
handled by the main thread with priority NORM_PRIORITY.
A quick fix may be to just leave the updater thread at the same
priority as the input thread (haven't had a chance to try that yet).
However, I think that the "right" fix is a bit more complex.
Giving priority to input is probably a good idea, since if we start
falling behind, skipping a few redraws is a good strategy. However,
giving *unconditional* priority to input for an unlimited time is not
viable. I think the right solution will involve more complex
communication between the threads so that if we get behind on the input
we skip some redraws, but that we don't block them out indefinitely.
We could consider a scheme which allowed inputs to have priority, but
to only process at most N inputs while there were pending redraws. If
the input thread detected that there had been N events processed while
redraw was pending, then it would explicitly block waiting on the
redraw thread to do at least some output (I think there is a fairly
straight forward monitor based solution for doing the control passing
needed here, but I have not yet worked out the details).
Perhaps a little better solution would take a similar approach, but
drive this off of explicit timing such that the input thread would not
block redraws for more than T ms. Choosing T is a balancing act
between feedback performance and the potential for falling behind on
input. Based on what I know about human perception, I'd start with
200 ms and see how that works. In the long run an adaptive scheme
may well be the way to choose T, but that's a research issue at this
point.
Another issue is an optimization of combining redundant/overlapping redraw
requests in the pending redraw queue, but that should probably be addressed
after dealing with the more serious problem caused by the priorities.
Scott Hudson
http://www.cc.gatech.edu/gvu/people/Faculty/Scott.E.Hudson.html
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
