471457 - SVG filters interact poorly with subpixel AA on text

Status: RESOLVED DUPLICATE of bug 812795

(Core :: SVG, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: testcase

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.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 2

[Bas Schouten (:bas.schouten)]

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

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?)

Comment 5

[Keith]

Attachment: Another testcase

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