How Windows 98 Handled Screen Redraw Under CPU Load

During periods of heavy CPU load, Microsoft Windows 98 managed screen redraw operations through an asynchronous, low-priority messaging architecture that frequently sacrificed visual fidelity in favor of system responsiveness. Because the operating system relied on direct-to-framebuffer rendering without a centralized compositing manager, high CPU utilization delayed the processing of paint messages, leading to characteristic visual anomalies such as incomplete redraws, frozen user interfaces, and the notorious "window ghosting" trail effect.

The Low-Priority WM_PAINT Message Queue

Windows 98 operated on an event-driven architecture powered by the Graphics Device Interface (GDI) and the USER subsystem. When an area of a window was uncovered or needed an update, the system marked that area as a "dirty" or invalid region.

Instead of repainting the invalid region instantly, Windows 98 generated a WM_PAINT message. Crucially, WM_PAINT was a synthetic, low-priority message. The operating system only dispatched WM_PAINT to an application when its message queue was completely empty of other pending messages, such as keyboard inputs, mouse movements, or internal process tasks. When an application or the CPU was pegged at 100% utilization, the thread rarely had idle cycles to process low-priority messages. Consequently, the window simply did not repaint, leaving the exposed region completely blank or filled with whatever artifacts were already in video memory.

Absence of Desktop Compositing

Modern operating systems retain a bitmap copy of every window off-screen in GPU memory, allowing the desktop to composite and display windows smoothly even if an underlying app crashes. Windows 98 lacked a compositing engine like the modern Desktop Window Manager (DWM).

Windows 98 utilized a single-buffered, direct rendering model by default:

• Applications drew directly to the primary video display buffer (front buffer).
• Windows were responsible for repainting their own client areas on demand.
• The operating system did not store the contents of occluded (covered) windows in memory.

When a user dragged a window across the screen, the system clipped out the old window area and marked the newly exposed pixels underneath as invalid, expecting the underlying program to immediately redraw that space.

The "Solitaire Effect" and Window Ghosting

Under heavy CPU load, this direct rendering model produced the well-known "window trail" or "Solitaire effect." If a background application was blocked by a CPU-intensive operation, it could not respond to the invalidation notices caused by moving a foreground window over it.

Because the background program failed to redraw its pixels, the foreground window's previous positions were never erased from the front framebuffer. As the user continued dragging, the foreground window left a persistent, stepped trail across the screen, repeatedly overwriting un-refreshed areas.

The Win16 Mutex Bottleneck

Windows 98 was a hybrid 16-bit and 32-bit operating system. While it supported 32-bit preemptive multitasking, critical graphics routines in GDI and USER still contained legacy 16-bit code protected by a single system-wide lock known as the "Win16Mutex."

If an application entered the 16-bit subsystem to draw graphics or handle window management and stalled due to heavy load, it retained the Win16Mutex lock. This effectively blocked all other applications—and often the desktop shell itself—from executing GDI redraw routines, stalling screen updates globally until the CPU freed up and released the lock.