| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
One of our DECwindows third-party asks the following: We are interested in the performance of DECwindows in general and the CPU loading on the client especially. We ran a series of tests, monitoring the CPU time, page faults, buffered and direct I/O counts for processes on both the client and server. The client application was running on a VAXserver 3600 and the server process(es) were running on a VAXstation 2000. The tests included seeing what happens when the user holds mouse button 1 (MB1) down for a period of time, in this case one minute. Holding MB1 down on a scroll bar track (not the button) used 15 seconds of CPU time on the client with negligable I/O, page faults or Ethernet traffic. Holding MB1 down on a scroll bar arrow head used 15.5 seconds of CPU time and resulted in less I/O and page faults. To us, it appears that when the client receives a MB1 down event in a scroll bar either on the track or arrow head, that the client application spends a lot of time in a tight loop and hence does very little I/O until the MB1 is released. In our test application, using DECwindows toolkit, we have two instances of scroll bars, one of which has no callbacks and one of which is used to display a list of picture names. The contents of the list for the latter are specified in the UIL description. No appreciable difference was found between the two when performing the above tests. When holding MB1 down on a scroll bar for one minute, as is the normal most common usage, 0.5 CPU seconds was used which is far more acceptable. Why is it using so much CPU time ? Could someone help me to answer to this customer many thanks Regards Maya
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 832.1 | I'll take a stab at explaining it | POOL::BALLOU | It's not slow, it's careful! | Wed May 24 1989 15:03 | 26 |
First, allow me to say that I have not looked at the code for the scrollbar widget. So, if anyone who is familiar with the code wants to correct what I say, please feel free to do so. An empirical conclusion, based on what is described in the base note and in a previous note on essentially the same topic: When MB1 is depressed in the scrollbar track or on the arrowheads, the widget responds by attempting to scroll. Once the scrollbar thumb has reached its extreme position, there's nowhere to scroll to. However, apparently the scrollbar widget keeps trying to scroll *continuously* until the mouse button is released. Therefore, the application eats up CPU time frantically trying to scroll until the user releases the mouse button. On the other hand, depressing MB1 while the cursor is positioned in the scrollbar thumb region does not generate repeated attempts to scroll. Presumably, the scrollbar widget simply notes that MB1 has been pressed and then attempts to scroll in response to mouse motion. Therefore, unlike the preceding case, holding the mouse button down does not consume CPU cycles. If my empirical observations are correct (by some random chance :-), perhaps it would be a good idea to modify the scrollbar widget not to generate scrolling attempts furiously once the scrollbar thumb has reached its extreme position? - Ken | |||||
| 832.2 | A simpler explanation - taking a cut at explaining whats in the black box | 40470::PETTENGILL | mulp | Thu May 25 1989 00:16 | 6 |
The client is simulating `autorepeat' of the button down. A button down on the arrow is auto repeated by the client doing timer events, but apparently no communication with the server. The button down on the scroll bar also autorepeats in a similar fashion. When the button down occurs in the slider, the client simply asks for motion events and waits for something to happen. | |||||