The Brutal Arithmetic of Post-Processing

The Cost of Beauty

Last Tuesday, we profiled a heavy-handed fragment shader on a mid-range Android handset. The thermal throttling hit at exactly the four-minute mark, dropping our frame rate from a smooth 60fps to a nauseating 22fps. The culprit? An over-engineered bloom pass that was sampling the source texture sixteen times per fragment. It looked gorgeous, but it was essentially a mobile furnace.

In our studio, we often see teams treat the GPU like an infinite resource. It is not. When you are writing WebGL, your primary constraint isn't creativity—it is the memory bandwidth and the thermal ceiling of a device you cannot control. If you push the pixels too hard, the OS will aggressively downclock your thread, and your elegant design will stutter into irrelevance.

The Downsampling Strategy

The standard advice is often lazy: 'use a full-screen quad and render everything to a single pass.' That is how you kill a battery. Instead, we advocate for aggressive, multi-stage downsampling. By rendering your effects to a lower-resolution buffer—perhaps half or even quarter size—you drastically reduce the number of texel fetches required in your Gaussian blur or color grading steps.

// Instead of a 1:1 render, downsample the target
const width = gl.drawingBufferWidth / 4;
const height = gl.drawingBufferHeight / 4;
gl.viewport(0, 0, width, height);
// Run your blur passes here...

The visual cost of downsampling is minimal compared to the performance gain. You can often recover the lost detail by utilizing a high-quality upscaling filter or a subtle sharpening pass, which is significantly cheaper than running a full-res blur.

The Shader Pipeline: Less is More

Stop chaining twenty fragment shaders together. Every time you switch programs, you incur a context-switching cost that kills the pipeline's efficiency. We prefer 'Uber-Shaders'—single shaders that handle multiple post-processing steps through conditional flags (uniforms). This keeps the instruction cache warm and avoids the overhead of repeated draw calls.

The most expensive pixel is the one you didn't need to shade in the first place.

Consider the logic within your fragment shaders carefully. Are you using pow() or sin() functions inside your loop? Those are expensive operations. Look for linear approximations or pre-computed lookup tables (LUTs). A 1D texture lookup for color grading is almost always faster than calculating complex math inside the shader.

Data Structures and Buffer Management

Memory thrashing is the silent killer. If you are creating and destroying framebuffers every frame, you are forcing the garbage collector to work harder than it should. We maintain a pool of reusable framebuffers. Once a texture is created, we recycle it across frames.

• Avoid Read-backs: Never use gl.readPixels if you can avoid it. It forces the GPU to synchronize with the CPU, stalling the entire pipeline.
• Texture Formats: Use RGBA4444 or RGB565 if the scene allows. High-bit-depth textures look great, but they consume twice the VRAM and bandwidth.
• Mipmaps: Even for post-processing, generating mipmaps for your downsampled buffers can speed up texture sampling significantly.

The Real-World Reality Check

We once spent an entire week chasing a memory leak that turned out to be a misplaced gl.deleteTexture call in an error-handling block. The browser's memory footprint grew by 50MB every minute. Mobile browsers are notoriously unforgiving with memory. If your app hits the 500MB ceiling, the page is gone. Period.

Testing on a high-end desktop is a trap. It lies to you. It tells you your code is efficient when it is merely being carried by brute force hardware. You must test on the lowest-end device you intend to support. If your frame time exceeds 16.6ms on a three-year-old iPhone, you have failed the user. Not because your art isn't good, but because you refused to respect the hardware.

Optimization is not a chore to be completed at the end of the project. It is the design process itself. If you build your pipeline with the limitations of a mobile battery as your first constraint, you will find that the resulting visuals are not just performant—they are disciplined. And in the world of creative engineering, discipline is the only thing that separates a hobbyist's demo from a professional product.