Section 8: How a Pixel Eventually Appears on Your Monitor (Complete Chain)

The Big Picture: One Journey, Many Stations

You now know all the stations. This section puts them in order and follows a single picture on its journey, from "a program wants to draw a button" to "light reaches your eye". Every step below comes from an earlier section, so use this page as a revision map.

 ┌──────────────────────────────────────────────────────────────┐
 │ 1. Application draws (calls a graphics API)                  │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 2. API runtime + user-mode driver build command buffers      │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 3. Kernel scheduler + kernel-mode driver hand them to GPU    │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 4. GPU runs the pipeline, draws into the BACK BUFFER         │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 5. DWM composes all windows into one desktop picture         │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 6. Swap: the finished picture becomes the FRONT BUFFER       │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 7. Display engine scans out row by row                       │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 8. Cable (HDMI / DisplayPort) carries the digital signal     │
 └──────────────────────────────┬───────────────────────────────┘
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 9. Monitor: scaler -> panel driver -> pixels -> light        │
 └──────────────────────────────────────────────────────────────┘

8.1 The Application Draws via a Graphics API

What happens: A program (a game, a browser, a text editor) wants something on the screen. It does not touch the GPU directly. It calls a graphics API (Section 3): Direct3D, OpenGL, Vulkan, or older GDI, or Direct2D for ordinary 2D drawing.

For a game, the calls are things like "load this texture", "set this shader", "draw these triangles". For a simple app such as Notepad, it is "draw this text here, this rectangle there".

The API runtime checks the calls and passes them on. Everything so far happens in user mode, inside the program's own process (Chapter 9).

8.2 The Driver Translates Commands to GPU Instructions

What happens: The user-mode driver (Section 2.2), written by the GPU maker, takes the API calls and turns them into command buffers: lists of instructions in the exact language of this particular GPU. It also compiles the shaders (Section 4) into the GPU's own machine code.

The buffers are then handed to Windows' graphics kernel (dxgkrnl.sys). Its scheduler decides when this program's work gets a turn on the GPU, and the kernel-mode driver sends the work to the hardware.

8.3 The GPU Executes the Rendering Pipeline

What happens: The GPU reads the command buffers from memory and runs them through the rendering pipeline (Section 4): vertex shader, rasterization, pixel shader, depth test, blending. Its thousands of small cores work on thousands of vertices and pixels at once.

While this is happening, the CPU is free to get on with other work, such as preparing the next frame. CPU and GPU work as a team, with the command buffers as the hand-over point.

8.4 The Completed Frame Is Written to the Frame Buffer

What happens: The output merger (the ROPs) writes the final colours into a back buffer: a block of VRAM that is not being shown yet (Section 7). The program then asks the API to present the frame.

Notice that on Windows, the program's picture usually does not go straight to the screen. It is first a window's contents: just one picture among others.

8.5 DWM Composes the Windows

What happens: Your screen shows many windows at once: the browser, a file explorer, the taskbar. Each program draws only its own window into its own surface in memory.

The DWM (Desktop Window Manager, dwm.exe), explained in Chapter 30 — Windows Desktop Internals, takes all these surfaces and composes them (puts them together) into one desktop picture: it adds window borders, shadows, transparency and animations, and sorts out which window is in front. The DWM uses the GPU to do it.

 Browser window ─┐
 Explorer window ─┼──▶  DWM  ──▶  one finished desktop picture
 Taskbar         ─┘               (windows, borders, shadows, taskbar)

(Some full-screen games can bypass parts of this process for lower delay. Windows decides this automatically, and the details vary between versions.)

8.6 The Frame Is Sent over HDMI or DisplayPort

What happens: The finished picture is swapped to become the front buffer (Section 7.1). The GPU's display engine then scans it out, row by row, as a digital signal (Section 7.2).

The signal goes through the cable to the monitor (Section 5). Before this, at plug-in, the monitor already told the PC what it can do, through the EDID (Section 5.6), so the PC knows which resolution and refresh rate to send.

8.7 The Monitor Scans and Displays the Frame

What happens inside the monitor is a chain of its own:

The picture is then complete. And 16.7 ms later, at 60 Hz, the whole chain starts again with a new frame.

Where Things Go Wrong

Knowing the chain helps with troubleshooting:

Summary