Spring 2008 6.831 User Interface Design and Implementation 1Lecture 23: Threads & Timers UI Hall of Fame or Shame?Spring 2008 6.831 User Interface Design and Implementation 2 Here’s our hall of fame or shame example. StatCounter is a web site that tracks usage statistics of your web site, using a hit counter. This is a sample of its statistics page, which shows you how many visitors your site had over a certain period of time. To help focus discussion, let’s think about: - color design - visual variables - the controls underneath the graph Today’s Topics• Long-running tasks• Threads•Timers• Event loop hacksSpring 2008 6.831 User Interface Design and Implementation 3 Today’s lecture is another in our series about implementing UIs. We’ll be talking about how to deal with long-running system tasks – i.e., computation or I/O that takes more than a short time to do, so you can’t simply do it in response to a user input event. We’ll look at three techniques for implementing these tasks: threads, timers, and event loop hacking, and discuss their applicability, advantages, and disadvantages.Long-Running Tasks• Some system tasks run for a long time– Getting a URL, running a database query, compiling a program• Event handlers should return quickly– Because repainting and input handling is blocked• But everything in a GUI is triggered by an event handler– e.g., pressing the button that starts the task• So long tasks need to run in the backgroundSpring 2008 6.831 User Interface Design and Implementation 4 First, some motivation. Why do we need to do background processing in graphical user interfaces? Even though computer systems are steadily getting faster, we’re also asking them to do more. Many programs need to do operations that may take some time: retrieving URLs over the network, running database queries, scanning a filesystem, doing complex calculations, etc. But graphical user interfaces are event-driven programs, which means (generally speaking) everything is triggered by an input event handler. For example, in a web browser, clicking a hyperlink starts loading a new web page. But if the click handler is written so that it actually retrieves the web page itself, then the web browser will have very poor usability. Why? Because its interface will actually freeze up until the click handler finishes retrieving the web page and returns to the event loop. It won’t repaint any damage to the window, and it won’t respond to any further user input. Most importantly, even if it displays a Stop button or a Cancel button for interrupting the download, the button will be completely unresponsive while the click handler is running. So long tasks need to run in the background. What’s a “long task”? Certainly anything shorter than the perceptual fusion interval, 100 msec, can be run directly in an event handler. But tasks longer than 1-5 sec should be cancellable. If a task needs to be cancelled, then it has to be run in the background, allowing the event loop to continue running so that the user can actually cancel it.Know Your Task’s Bottleneck• Input from user– Most desktop and web UIs spend almost all their time waiting for the user to do something• Output to user– Animation•CPU/memory– Compute-bound processing• I/O– Network, filesystem, devicesSpring 2008 6.831 User Interface Design and Implementation 5 Before discussing the techniques for background processing, it’s important to be aware of what kind of task you’re running. What is its performance bottleneck – i.e., how does it spend most of its time? For most GUIs, the bottleneck is actually user input. The program spends most of its time sitting in the event loop, waiting patiently for the user to do something. When the user does provide some input, the program’s event handlers fire, compute a change, and repaint the result. Then the program sits and waits again. Users are so slow relative to the computer system that this kind of system doesn’t need any background processing; it can do everything in the event loop. When user output is the bottleneck, the program spends most of its time drawing on the screen, because the display is changing independently of the user’s input. 3D games, video players, and animation-heavy programs typically face this problem. We’ll talk more about animation in a future lecture. The other two bottlenecks are the most relevant to today’s lecture. CPU or memory might be a bottleneck for systems that need to do a lot of local processing. Searching for the shortest path through an enormous graph might be a compute-bound task, for example. I/O might be a bottleneck for tasks that need to read or write a lot of data from the network or filesystem, or interact with a device like a CD burner. For I/O-bound tasks (just like user-input-bound tasks), the CPU spends most of its time waiting – e.g., waiting for a remote web server to respond, or waiting for more bytes to arrive across the network, or waiting for a disk to seek to the right track. Note that many tasks might involve both CPU work and I/O; what we care about is which one is the bottleneck. If a task involves a small file from the local disk and then proceeds to decrypt it using an expensive decryption algorithm, then overall the task is CPU-bound. If, on the other hand, the task involves fetching a large file over a distant network connection and then unzipping it with a fast decompressor, then overall the task is probably I/O-bound.Goals• Handle UI input and output constantly– Respond to input events within 100 msec– Handle repaints too• Display task progress– e.g. progress bar• Allow task to be canceled– Cancel button• Don’t hog the CPUSpring 2008 6.831 User Interface Design and Implementation 6 Here are the goals we want to satisfy when we implement handling for long tasks. First, while the task is running, we want to handle UI input and output constantly. The event loop should keep spinning, reading input events from the event queue, dispatching them to event handlers, and handling repaint requests to keep the display up to date. To preserve good response times, we should make sure input events don’t sit on the queue unhandled for very long – 100 msec would be the upper limit on the age of an event before it’s handled. Second, if the long task was requested by the user, or if the user is waiting for its results, then
View Full Document
Unlocking...