Windows 3.11 Graphics Clipping in Overlapping Windows

In Microsoft Windows 3.11, graphics clipping for overlapping application windows was managed by the 16-bit Graphics Device Interface (GDI) in coordination with the USER module. By maintaining window hierarchy and Z-order, the operating system dynamically computed visible clipping regions for each window, restricting drawing operations to non-obscured areas and preventing background applications from overwriting foreground content.

The Role of GDI and Device Contexts

In Windows 3.11, applications did not write directly to the screen hardware. Instead, graphics were rendered through a Device Context (DC), an internal GDI structure that encapsulated drawing tools, color mappings, and clipping attributes. When an application requested a DC via functions like GetDC() or BeginPaint(), GDI established the boundaries within which that application was permitted to render.

Z-Order and Region Math

The USER module tracked the screen position, dimensions, and Z-order (depth order) of every active window. When a window was partially covered by another, Windows calculated its visible region using region algebra:

  1. Window Rectangles: The system started with the application window's client rectangle.
  2. Subtraction of Occluding Windows: GDI inspected all sibling windows positioned higher in the Z-order. The intersecting areas of these overlapping windows were subtracted from the target window's area.
  3. Parent Clipping: If the window was a child control (such as a button or edit box), its area was additionally clipped against the client boundary of its parent window.

The resulting visible area was rarely a simple rectangle. Instead, GDI represented it as a complex clipping region (HRGN). Internally, these regions were stored as collections of non-overlapping, contiguous horizontal rectangular strips sorted along the Y-axis.

The Paint Cycle and Update Regions

When an overlapping window moved, closed, or resized, the previously obscured area became "dirty" or invalidated. Windows 3.11 handled this through an event-driven redraw process:

  1. The system marked the exposed area as an Update Region.
  2. A WM_PAINT message was posted to the application's message queue.
  3. The application called BeginPaint(), which intersected the window's total visible region with the update region to form the final clipping region for that paint cycle.
  4. GDI then validated the dirty region, resetting the update state.

This mechanism ensured that applications only recalculated and rendered pixels in the exact portions of the window that actually required updating, conserving CPU cycles on limited 16-bit hardware.

Clipping Execution at the Driver Level

When GDI functions such as BitBlt(), Rectangle(), or LineTo() were invoked, GDI evaluated the target coordinates against the clipping region before writing to the frame buffer:

  • Trivial Rejection: GDI checked the bounding box of the graphic primitive against the bounding box of the clipping region. If they did not intersect, the operation was aborted immediately.
  • Complex Clipping: If the primitive intersected a non-rectangular region, GDI iterated through the individual rectangular spans comprising that region. The drawing operation was clipped to each span, executing multiple constrained blits or raster operations.
  • Display Driver Offloading: Standard display drivers (such as the 16-color VGA or SVGA drivers) received clipped coordinates from GDI, ensuring memory writes stayed strictly within the allocated frame buffer addresses corresponding to the visible pixels.