A phenomenon that can be observed with Swing running under Windows 95 and perhaps on other platforms as well, is that many widgets such as JPopupMenu and JOptionDialog takes virtually forever - about 2 seconds in real time, to display the first time they are executed. This may be not a major problem for some widgets such as menus where the user has a great expectancy that it will show. A delay in feedback is more than just an annoyance for pop up menus. The reason for this is, the user will only wait a very short amount of time after right clicking, for the pop up menu to appear, before deciding that a context sensitive operation is not available. Most users can only tolerate up to 8.5 seconds of non-response from the user interface before hitting the reset button ( Bickford, p128 ). Bickford recommends that programs should respond immediately to user actions, preferably in 0.2 seconds or less. For context sensitive popup menus, the time it takes for the user to decide that it is not available is about 2 seconds. This figure was obtained by experiment with a helpful roommate, who was asked to evaluate two programs, one more responsive than the other. The more responsive program incorporated code that used the preloading technique to speed up initial displays of widgets. This is technique similar to preloading data into caches so that the next time the data is needed, it can quickly be accessed. In fact, that is probably what happens with the Swing user interface widgets. Because Swing has a pluggable look and feel, it must look up the "instructions" on how to render a particular widget for a given look and feel, at least for the first time it is displayed. Swing does this through the object-oriented pattern of Factory Method. This scheme slows things down the first time a widget is displayed. The apparent difference in speed between the first and subsequent rendering could also be exaggerated by the JIT mechanism that comes with the virtual machine on some platforms such as Windows 95.
The trick to preloading is moving the delay time for a widget to load from where it is most inconvenient, i.e right after an user action, to place where delays are better tolerated such as when the program is first loaded. Preloading is accomplished by forcing widgets to execute even before the main user interface shows. Won’t the widget pop up and cause strange artifacts? Actually on a modern machine, the on-screen time of a widget being executed and closed right after, is so small that the eye does not even notice it. Subliminal programming would be an apt label for this feat. An appropriate place to put preloading code is right before the display of the main user interface frame, after the resources for the frame has been allocated. This is important because many widgets cannot be displayed without a parent widget such as the main frame. An example of how a pop up menu can be preloaded is given in the following code fragment. Notice that the code resides in the main frame window opening event handler.
public void windowOpened(WindowEvent e)
{
mouseHandler.mousePressed( (MouseEvent)null );
m.show( StructuredMatcherView.this, 0, 0 );
m.setVisible( false );
}
where m is the handle to pop up menu. The pop up menu is shown and immediately closed in the next line. The mouse event handler for context operations is also preloaded so to give the JIT an opportunity to perform it’s optimisations.
As a result of this piece of code, the pop up menu responds in 1 second
as opposed to 2 seconds , the first time a user invokes a context sensitive
operation. This is a 100% improvement. Subsequent pop up menu invocation
response times are almost immediate both in the optimized and un-optimized
versions of the program. Efforts to make the pop up menu respond this quickly
for the first time will require much delving into the innards of the Java
virtual machine and the user interface code and is beyond the scope of
the project.