In Chapter 3 we discussed the graphics architecture of Windows NT. The illustration is reproduced here to jog your memory. When an application wants to write to the display it must send its request to the Client Server Runtime System (CSRSS). (This is called a client-server architecture because it mimics the network client-server model we covered in detail in Chapter 7. However, the client and the server for graphics in Windows NT must be on the same computer because, as we shall see, they share common data.) This provides a high degree of portable protection to the windowing and graphics managers, but there is a cost of about a thousand instructions for each call. This fact dominates life in graphics land on Windows NT and has important implications for how you code your application.
Figure 9.1 Windows NT client-server graphics architecture
You might wonder why we did not just use another protection ring and place the windowing system there. This would have kept it out of privileged mode and still protected it from the applications. The reason is that many machines only have the two protection levels: user and privileged modes. If we had tried to use a third level, Windows NT would not have been portable.
One way the system improves on the effective per-call cost of the client-server transition is to batch up calls and send them together. This gets them over to CSRSS at a "bulk rate." Several events can trigger the release of a batch of calls to CSRSS. If too much time passes between calls, the current batch is released. If too many calls pile up, the batch is released (ten is the default batch limit). And certain calls (those that require the graphics display to be updated in order to return their values) will "flush the batch." We'll discuss these in a moment.
In order to minimize the number of transitions to the CSRSS process, the system caches quite a bit of information in the application process. For example, the first time the application requests font metrics much of the information for responding to questions about the metrics on the font is copied to the application process for further reference. Another thing that applications do a lot is compute transforms between the logical and physical display coordinates, so the information for these transforms is cached in the application. Basically, anything frequently used that can be changed only by the application is cached. Anything that other applications using the windows and graphics subsystems can change cannot be cached in the application, but must be retained in CSRSS.
Another thing Windows NT does to minimize the need to cross over to CSRSS is to share, as read-only, some of the CSRSS address space with the application. This permits windows calls which need to read information in CSRSS data structures to do so without having to transfer to the CSRSS process to look at the data. An example here is the application's message queue. By mapping it to the address space of the application, the system can avoid a transition to CSRSS to determine if a message is waiting in the queue, as is done in a PeekMessage call. The system also maps data about such commonly-referenced items as existing windows, menus, and system colors.