Securing graphical user interfaces

ion such as a widget set including buttons, menus, and other basic GUI elements. Performing the transformation of each client’s representation to pixels locally enables the GUI server to predict all graphical primitives that are needed for any screen update and, as a consequence, to estimate overall execution times of redrawing jobs in advance of execution. The sequence of graphical primitives is a function of both the known transformation of the GUI client’s representations to pixels and the actual window layout. The latter, however, may have a significant influence on the required graphical primitives but is not known at admission time of a GUI client. This problem is best illustrated by the painter’s algorithm as used by the Windows Vista’s Desktop Window Manager (DWM), the Quartz window manager of Mac OS X, and the composite extension of the X window system. Deficiency of the painter’s algorithm As a painter, the algorithm produces the final image by painting all objects ordered by their distance from the viewer, starting with the rearmost (background) and finishing with the foremost (top window). In the final image, window portions that are covered by other windows get correctly over-painted and are no longer visible. Combined with the use of alpha channels, which is comparable with applying layers of watercolor with different translucencies to a canvas, this algorithm provides maximum flexibility with regard to the shapes of windows and their opacity. With regard to predicting redraw-execution times however, this algorithm is not well suited. Even though the sequence of graphical primitives used by the Painter’s Algorithm can be determined immediately prior execution, we cannot predict a realistic redraw execution time for a specific GUI client at its admission time because the actual costs depend on the other GUI clients and on the window layout, which is not fixed during the lifetime of the GUI client. Therefore, the admission of new GUI clients is based on an overly pessimistic worst-case redraw-execution time assuming that all windows are covering each other and thus, must be painted for each redraw operation. Decoupling redraw-execution times of different clients To dissolve the inter-dependency of windows from each other during the redraw of one particular window (target window), the painting algorithm should limit its operation to only the target window but should not paint the windows of any other windows. This can be achieved by preceding the painting operation by a geometric analysis that computes the target window’s visible portion. The visible portion is determined by successively cutting out the shape of each window in front of the target window from the target window’s shape. Such a technique was originally employed by most window systems but current-generation commodity GUIs discarded this approach in favour of executing the painters algorithm via hardware-accelerated graphics. Figure 2.2 illustrates this procedure. The resulting shape is then used as clipping boundary while painting the target window to mask out all pixels that are covered by other windows. The worst-case redraw-execution time for each window corresponds to painting the window when fully exposed and it is invariant toward the presence of other windows and the window layout (ignoring the computational overhead for the geometric analysis at this point). With known temporal characteristics of the single graphical primitives, this technique enables us to predict redraw-execution times prior execution and, therefore, base the admission of GUI clients on realistic worst-case execution times. 2.2.2 Local scheduling of redrawing jobs With the satisfied precondition of known worst-case redraw-execution times, the construction of the GUI server as a periodic process clears the way for deploying the full variety of well-