So I Tried To Learn Shaders...

Shaders become understandable once they’re treated as massively parallel “pixel programs”: a fragment shader runs for every pixel on the screen, using the pixel’s screen coordinates to compute a color. The core learning arc here is moving from confusion about how pixels get their inputs (and how “blur” works) to a working mental model of GPU execution: thousands to millions of tiny tasks run in parallel, each one largely independent, which is why shader code is written as functions of position and time rather than step-by-step logic.

The transcript starts with a personal history of failing to grasp shader math from a book example years earlier—light swinging to create shadows and penumbras. That earlier failure becomes the motivation for a gentler rebuild: what a shader is, how it differs from CPU-style sequential programs, and why GPUs are built for parallel throughput. A CPU metaphor of “pipes” and “threads” leads into the practical reality: every frame requires computing color for hundreds of thousands of pixels (e.g., 800×600 is 480,000 pixels per frame), and high resolutions multiply that workload dramatically. This is the reason shaders feel “fast” when they’re written in the right style: the GPU architecture is designed to keep many small operations busy at once.

From there, the learning shifts into concrete WebGL/GLSL mechanics. The transcript introduces GLSL basics (vertex vs. fragment shaders), the idea of built-in variables like GL frag color and gl_FragCoord, and the importance of precision qualifiers (e.g., medium float). It also emphasizes that shader debugging is awkward: there’s no normal console logging, and mistakes often show up as a white screen or compilation errors. The practical workaround is iterative experimentation—changing values, forcing strong colors, and using shader logs when available.

A major milestone is getting a “hello world” style output: cornflower blue via a minimal WebGL pipeline (create context, compile shaders, link a program, draw). Then comes the real conceptual payoff: uniforms. Uniforms are read-only inputs set by the host (JavaScript) that remain constant across all fragment invocations during a draw call. The transcript uses uniforms like u_time, u_resolution, and u_mouse to drive animation and interaction, explaining how the same shader code can produce different results depending on those global inputs.

The transcript then dives into coordinate spaces and why results look “wrong” until the right space is used. It distinguishes vertex coordinates, fragment coordinates, and normalized device coordinates, and repeatedly corrects assumptions about where (0,0) lies and what range gl_FragCoord uses. Once coordinates are correct, the shader becomes a playground for math-driven visuals: distance fields (distance from the mouse), gradients, and time-based sine waves.

Finally, the transcript explores shaping functions—especially smoothstep—as a way to draw crisp lines and controlled transitions without branching. The “fence” exercise demonstrates how smoothstep creates an S-curve transition around a threshold, producing a thin green line where a condition like y≈x holds, while the rest of the screen stays mostly unchanged. The session ends with the broader takeaway: shaders are less about “debugging a program” and more about mastering math-to-image transformations, using parallelism-friendly functions of position, time, and uniforms to build increasingly complex visuals.