Death by 1000 Draw Calls: WebGL Post-Processing That Doesn't Melt the GPU

The Cost of Vanity

Every time a designer asks for 'just a subtle bloom' or 'a slight chromatic aberration overlay' on top of a heavy WebGL scene, my internal clock starts counting the milliseconds until the laptop fan kicks in. We treat the browser like a desktop engine, pushing massive framebuffers around with complete disregard for the mobile thermal envelope. On a modern iPhone, if you exceed your thermal budget, the OS throttles the GPU clock speed, turning your silky 60fps interaction into a slideshow. It is not the browser's fault; it is ours.

The standard industry approach is a bloated chain: depth-of-field, lens distortion, color grading, and bloom, all rendered as separate textures. Each pass is a full-screen draw call. You are effectively clearing the GPU cache and stalling the pipeline four or five times per frame. If you are doing this on a 3x pixel density display, you are pushing millions of fragments every 16.6ms. Stop it.

Baking Before Rendering

The most expensive pixels are the ones you recalculate every frame. If your post-processing effect is static—like a grain texture or a subtle vignetting mask—stop generating it in GLSL. Bake it into the viewport texture before the main render loop starts. Even better, leverage CSS backdrop-filter where possible. I know, it feels like cheating, but the browser engine optimizes hardware compositing for static overlays far better than any hand-rolled fragment shader will.

The Downsample Strategy

Never, and I mean never, perform high-intensity post-processing at native device resolution. Your eyes cannot tell the difference between a native-res bloom and a 1/4 resolution bloom once it’s blurred. The math here is simple:

• Native render target: 2000x1000 (2M pixels)
• 1/4 resolution render target: 500x250 (0.125M pixels)

By downsampling your input to a ping-pong buffer, you reduce the fragment load by 93%. If you are using three.js or custom WebGL wrappers, check your WebGLRenderTarget settings. If you aren't using power-of-two textures or proper Mipmaps, your GPU is likely spending cycles on texture interpolation that it doesn't need to.

Writing Leaner Shaders

We often fall into the trap of 'mega-shaders'. It feels cleaner to have one giant fragment shader with 15 if statements and branching logic. On modern GPUs, branching is death. The hardware is designed for SIMD (Single Instruction, Multiple Data) operations. When you introduce a conditional branch, you risk stalling all parallel threads in the warp if they disagree on the outcome.

// Avoid this logic
if (u_enableBloom) {
    vec3 bloom = calculateBloom();
    color += bloom;
}

// Do this instead: Pre-calculate the bloom in a separate pass
// or bake the intensity into a single multiply uniform.
color += bloom * u_bloomIntensity;

The Mobile Reality Check

When we profiled our last major project—a high-fidelity product configurator—we found that 40% of our power consumption wasn't the WebGL scene itself. It was the frame-to-screen blit operation because we were swapping textures every frame without reusing memory buffers. Reuse your buffers. Allocate two `WebGLRenderTarget` objects and toggle between them like a tennis match. Never instantiate a new texture in the render loop; the garbage collector will eventually pause your main thread, and the user will notice that hiccup every single time.

The goal is not to have the most shaders; the goal is to have the fewest.

If you have to pick one battle to fight, make it the texture resolution of your buffers. Most developers default to window.devicePixelRatio. On a mobile phone, that is often 3.0. Do you really need a 3x resolution bloom buffer? No. Cap your internal render targets at 1.5x or even 1.0x regardless of the screen density. The user won't notice the blur, but their battery will thank you for the extra hour of life.

We are engineering experiences, not slide decks. If your project works perfectly on your RTX 4090 but makes a mid-range Android phone hot to the touch, it is not a technical triumph. It is a failure of empathy for the user's hardware. Optimization is not just about performance; it's about accessibility. Make your code run on the hardware that exists, not the hardware you wish your users owned.