I think there's another similar bug on file, but I can't find it. It might be related to the opacity/subpixel AA looking bad bugs we have. If you apply a SVG filter to a colored block of text, the colors change drastically; I'm guessing the text is composited against white (or black) into the temporary buffer instead of whatever the background color actually is. IMO, we need to turn off subpixel AA if we have SVG filters involved. In the testcase, the right block has just a simple feMerge with SourceGraphic (that is, a noop, but that goes through the filter mechanics). The colors, at least on Windows, are very different from the left.

Is this just http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-win32-font.c#1407 ? Are the results for the filter the same as if the text was rgba(..., 0.99) or opacity:0.99?

DirectWrite build does not suffer from this behavior, see bug 517642.

This doesn't seem to happen on Windows XP; is that the boundary for where ClearType became on-by-default? I heard people complaining about http://dbaron.org/mozilla/invert-colors#http://tests.themasta.com/tinderboxpushlog/ on either Windows Vista or 7, but it's fine on XP. (There also seem to be problems on some Mac OS X machines (mrbkap's laptop, but not my 10.4 desktop) with the blue text on a black background in that page. Should we have a separate bug on file for Mac?)

Using drop-shadow filter based on http://xn--dahlstrm-t4a.net/svg/filters/arrow-with-dropshadow.svg.