AGG2.5版本中agg::pixfmt_rgba32_plain计算颜色错误问题y以及修复

I’ve gone ahead and upgraded matplotlib from agg-2.4 to current agg SVN. 
Overall, pretty painless, thanks.

However, I’m running into one problem that is resulting in all the 
colors being slightly off from before.

The rendering buffer is of type agg::pixfmt_rgba32_plain, and it’s 
initialized to all zeros.

In agg-2.4, if I draw a rectangle path with RGB value of (0, 255, 102, 
64), the resulting pixel value is (0, 255, 102, 64).

In agg-svn, I get (0, 255, 104, 64).

This slight difference has cumulative effects that are not desirable.

I’ve tracked down the difference in code to blender_rgba_plain::blend_pix.

In agg-2.4, I have:

Inputs:
p = {0, 0, 0, 0}
cr = 0
cg = 255
cb = 102
alpha = 64

Therefore:
a = ((alpha + a) << base_shift) - alpha * a;
a = 16384

p[G] = ((((cg << base_shift) - g) * alpha + (g << base_shift)) / a)
g = 102

I’m having trouble tracing the order of execution in the SVN version of 
Agg, but it seems the difference is not so much in anything intentional 
but from the fact that everything but the final demultiply is downgraded 
to color_type, and then the demultiply happens. Whereas in the old 
version, it’s still doing calculations in calc_type (uint16) up until 
the final demultiply.

Does that make sense, or am I doing something wrong?

I’m using a non-premultiplied buffer, because ultimately these things 
are saved to PNG, which wants non-premultiplied data. I tried changing 
to a pre-multiplied buffer, and then demultiplying immediately before 
saving to the file, but that has the same numerical issue as far as I 
can tell.

解决方案：
Patch: truncating in opacity is broken

At some point between Agg-2.4 and the current SVN, this:
const rgba& opacity(double a_) { if(a_ < 0.0) a_ = 0.0; if(a_ > 1.0) a_ = 1.0; a = a_; return *this; }
was changed to:
rgba& opacity(double a_) { if (a_ < 0) a_ = 0; else if (a_ > 1) a_ = 1; else a = a_; return *this; }
in a number of places. Note that in the latter, the truncation actually has no effect, and it only results in no opacity being set at all on the color.
The attached patch addresses this.

Yes, I see the problem. I suppose it must have happened when refactoring for the floating-point support.