No white circles anymore, yes .
For me, it's a kind of bug. I hope the devlopers can fixe it one day (I'm so sorry I can't help). Lots of new works would be possible with a more efficient alpha.
It isn't like the color bug. Even if you take out the recursion and just draw one circle the color of that circle is (253,253,253) instead of (255,255,255). The HSBA color is correctly converted to RGBA. The problem happens inside of the AGG template library.
I don't know for sure, but I think that the AGG library might have several off-by-one errors in its alpha-blending. There are several places where AGG does a fast '>> 8' when it seems to me that the slower '/ 255' is more correct. I replaced several '>> 8' with '/ 255' in the color pre-multiplier and pixel blender functions and the gray circles changed to pure white (255,255,255). I am pursuing this issue in the AGG mailing list.
I have confirmed that the AGG graphics template library that Context Free uses fudges alpha blending in the way that I described earlier, in order to run faster. But I did get a pointer to a 1995 research paper on how to do exact alpha blending using only shifts and adds, with no slow divides. I have updated AGG for the 2.1beta version here with with this technique. The above cfdg code renders perfectly white using the new alpha blending code. There is a 5-10% slow-down in drawing. I think it is worth it.
Unfortunately some people have compensated for the darkened alpha blending bug by lightening there shape colors. With 2.1beta (and beyond) these will seem to be too light.
No the circles should all be 50% transparent. The alpha for rule TEST starts at 1. When you do TEST{x .993 r 12 s .993 alpha .01}, you are making alpha 10% more opaque, but the alpha is already at 100% opacity so the alpha .01 does nothing. What you want is to use another rule to change alpha for TEST to 50%:
Note that it affects both solid areas and anti-aliasing.
It's pretty common, but given AGG's declared goals I don't know why they discard colour information in the first place. Or why the background isn't used to supply it.
Many images for which CF would be ideally suited also involve situations in which this error becomes prominent. Seriously compromised my latest idea, anyway. *grumble*
If you get rid of the sat -1 then the problem goes away. If you make the background slightly transparent then the problem goes away. It turns out that when I fixed alpha in AGG I forgot to do it for the 24-bit pixel formats. I only did it for 8 and 32-bit pixel formats. I will fix 24-bit pixels in the next beta release.
Hooray!
Thanks. I was going to ask about an interim fix, but couldn't see that anything would get around it. (Hm, internal mode switch perhaps?)
The transparent background trick works brilliantly.
Also, a -.001 renders as opaque, so there's never any need to compensate elsewhere.
No amount of fiddling with sat made any difference for me, though -- Removing "sat -1" (which is only the default made explicit), or increasing sat to any value (including 1).
But I can think of no situation for which the first fix isn't preferable anyway.
Yes, as you said the transparent background trick works brilliantly. Increasing sat to any value including one.
================================================
casseysmith