Windows 3.11 GDI Vector Graphics Rendering

In Microsoft Windows 3.11, vector graphics were rendered using the Graphics Device Interface (GDI), a 16-bit core system component that translated mathematical geometric commands into device-specific pixel outputs. Operating as an abstraction layer between user applications and display hardware, GDI utilized Device Contexts (DCs), built-in scan-conversion algorithms, and display drivers to achieve resolution-independent line drawing, shape rasterization, and TrueType font rendering without requiring developers to write hardware-specific code.

The Device Context and Coordinate Mapping

Rendering began with an application requesting a handle to a Device Context (HDC). The Device Context stored the drawing state, including selected pen colors, brush styles, background modes, clipping regions, and mapping modes.

Windows 3.11 relied on mapping modes to define how logical units specified in code translated to physical device pixels:

  • MM_TEXT: Mapped one logical unit directly to one device pixel.
  • Metric Modes (MM_LOMETRIC, MM_HIMETRIC, MM_LOENGLISH, MM_HIENGLISH, MM_TWIPS): Allowed programs to define vector shapes in real-world measurements, which GDI dynamically scaled based on the reported physical dimensions and DPI of the output display or printer.
  • MM_ISOTROPIC and MM_ANISOTROPIC: Enabled arbitrary scaling, coordinate inversion, and aspect-ratio preservation across arbitrary viewport boundaries.

Vector Drawing Primitives

Applications drew vectors by calling procedural GDI primitives. Rather than passing raw bitmaps, programs submitted mathematical parameters:

  • Lines and Curves: Functions such as MoveTo() and LineTo() established path trajectories, while Arc() defined elliptical segments calculated using a bounding box and radial start/end points.
  • Closed Shapes: Calls like Rectangle(), RoundRect(), Ellipse(), and Polygon() defined closed geometric boundaries.
  • Pens and Brushes: A logical pen (HPEN) determined the vector outline’s color, width, and style (solid, dashed, dotted), while a logical brush (HBRUSH) determined interior fill patterns.

Scan Conversion and Software Rasterization

Because typical consumer SVGA and VGA graphics cards in the early 1990s lacked hardware-accelerated 2D geometric engines, Windows 3.11 executed the mathematical rasterization on the host CPU (typically an Intel 80386 or 80486).

  1. Edge Calculation: GDI’s software rasterizer used Bresenham's line algorithm to calculate pixel coordinates between floating or integer endpoints for straight lines and polygon edges.
  2. Polygon Filling: For filled shapes, GDI tracked horizontal scanline intersections using either an alternating (even-odd) or winding fill rule (SetPolyFillMode). It then populated horizontal spans (runs of pixels) using the active brush pattern.
  3. Clipping: Before writing to memory, coordinates were bounded against the clipping region. GDI computed mathematical intersections to ensure vector lines never drew outside designated window boundaries or overlapping child controls.

TrueType Font Outline Rasterization

Windows 3.11 treated TrueType typography as vector geometry. Instead of relying purely on fixed-size bitmap fonts, GDI included a TrueType rasterizer that read scalable glyph outlines composed of straight lines and quadratic Bézier curves.

When a text string was drawn via TextOut(), the rasterizer:

  1. Scaled the glyph's vector control points to the requested point size.
  2. Applied hinting bytecode embedded in the font file to align vector boundaries with the display's discrete pixel grid.
  3. Converted the Bézier equations into raster scanlines, caching frequently used glyph bitmaps in system memory to maintain real-time rendering speeds.

The Role of Display Drivers (DDI)

At the final stage of rendering, GDI interacted with the graphics hardware via the Device Driver Interface (DDI). The driver (.DRV) declared its capabilities to GDI using device technology flags:

  • Hardware Acceleration: If high-end display hardware provided dedicated acceleration for specific primitives (such as solid rectangular fills or bit-block transfers), the driver handled the operation directly.
  • Software Fallback: If the driver lacked native primitive routines, GDI synthesized the shape internally in software memory and transferred the resulting pixel data to video RAM using basic BitBlt operations or direct frame-buffer memory writes.

Windows Metafiles (WMF)

For saving and exchanging vector graphics between applications (such as Microsoft Word and CorelDRAW), Windows 3.11 utilized the Windows Metafile (.WMF) format. A metafile acted as a serialized recording of GDI vector instructions. When an application opened a metafile, it invoked PlayMetaFile(), causing GDI to parse the stored list of drawing calls and replay the vector equations directly into the target Device Context at the target device's native resolution.