Gecko doesn't use sub-pixel antialiasing for SVG text. This is one of the reasons SVG text looks worse in Gecko than in WebKit. Tested with Firefox trunk and WebKit trunk on a MacBook Pro.

(Gecko uses grayscale antialiasing, which is much better than nothing but not as good as sub-pixel.)

Related to bug 379786 maybe.

Subpixel anti-aliasing relies on blitting text directly into the window context. If text is blit to an offscreen, then blended with the window context, the subpixel alpha information is lost in the process. See bug 379786 for details. So this bug boils down to whether SVG can be drawn directly to the window context or if it must go via an offscreen.

Tor, are we using an intermediate buffer for SVG drawing for some reason? Can we get rid of that?

(In reply to comment #5) > Tor, are we using an intermediate buffer for SVG drawing for some reason? Can > we get rid of that? Yes, on OS-X we paint SVG into a pushed surface and show it at the end (nsSVGOuterFrame.cpp:432) due to limitations of the quartz backend that needed a non-window target for fallbacks. I'm not sure if these problems still exist.

Sounds like we need a new bug to add the needed Quartz backend routines. Any idea which ones are needed?

No, there are no needed Quartz backend routines -- it is not possible to do any fallback rendering when drawing to a window context; you can't get the bits. So SVG has no choice but to use push/pop group... Now, the number of cases where fallback is needed is very small I think; it was mainly due to mask(), which I believe brian ewins has implemented (though I'm not sure if that's in our latest code drop), so maybe this won't be needed any more.

Fixed by checkin for bug 411334. I checked in a reftest for this as well. Note that certain SVG constructs will trigger fallback which will make this bug reappear for all text in the same SVG subtree. Such issues should be fixed by making those constructs not trigger fallback in cairo.