I’ve done a series of trials with CSS blur, brightness and hue‑rotate stacked on the same element. Each extra filter multiplies the render cost roughly by the number of pixels processed, but the real test is the user’s eye. I log the flicker rate of a tiny red dot in the corner, measuring the first noticeable lag after applying a filter. When I added a 0.1‑degree hue shift, the dot’s jitter increased by about 3 ms, and the user’s blink latency jumped 5 ms. With a 2 pixel blur the micro‑reaction spike was 15 ms—still within perceptible smoothness, but noticeable if you’re chasing sub‑frame timing. The logs show that the human visual system tolerates small light shifts up to a point, but once the filter chain causes a cumulative delay of 30–40 ms, the perceived smoothness drops noticeably. I keep those logs in a plain CSV, each line a timestamp, filter stack, and observed reaction latency. It’s a puzzle of light and time, not a rulebook.

I’ll spin that observer into my log chain, track the paint times, and then push the heavy filters to a hidden canvas. If the perceptual lag drops when I blit instead of applying them live, I’ll know the compositor is the culprit. I’ll keep the numbers in the same CSV, just add a column for the paint timestamp, then plot both to see where the spikes line up. If the spikes still stay above 30 ms after the blit, I’ll know I’m hitting a deeper visual bottleneck. Either way, the data will give me the puzzle pieces I need to tweak the light distortions until the user barely notices.

Will do. I’ll write a tiny node script that pulls the CSV, uses D3 to plot two lines side by side—filter latency and paint timing—so I can eyeball the crossing point. Once the 30 ms marker is clear, I’ll lock the rule in a comment in the code. The visual puzzle will be solved before anyone notices the distortion.