Assertion failure: false (Skia and DirectWrite do not mix), at ScaledFontDWrite.h:40 This assertion was added in bug 780392. The DOM fuzzer is hitting this a lot on the Windows builders. The testcases tend to be simple, like just creating a canvas and calling strokeText. But I can't reproduce the assertion failure on my own Windows machine.

This is odd... skia shouldn't be used by default on windows. This would occur if Skia was somehow preffed on manually for canvas usage and you were creating a surface larger than 8192x8192.

I believe Skia is on by default for unaccelerated Windows, but then we shouldn't have DirectWrite, right?

(In reply to George Wright (:gw280) from comment #2) > I believe Skia is on by default for unaccelerated Windows, but then we > shouldn't have DirectWrite, right? It is? I was under the impression we'd be using Cairo ... I've heard nothing of Skia being the default on windows, ever? I thought it wasn't universally better so that call had not been made. Note that our font cache will have DirectWrite fonts on these systems so there's nothing we can do there. We'd have to add DirectWrite support to Skia.

See bug 831525

Bug 831525 was titled "Enable Skia canvas rendering on windows xp". On XP, we should always have GDI fonts, not DirectWrite ones. On Vista and later, we'd normally have GDI fonts if acceleration is disabled, but users can explicitly turn on DirectWrite (in about:config) even then. Hmm, on looking at the patch in 831525, it adds skia to the backends for all versions of Windows, not just for XP. Was that intended? Are there circumstances where acceleration is enabled (and so we'll have DW fonts), but the direct2d azure backend will fail, so that it'll fall back to skia (which is now next in the list)? It all sounds a bit confused and fragile to me...

I was under the understanding that this situation was only possible with custom pref settings (force enabling DWrite, and disabling direct2d/direct3d).

I think this is a dup of bug 842521. My suggestion there was to just disable skia (and fallback to cairo) if DWrite is enabled. Adding DWrite support to skia doesn't appear to be easy, since the code appears to be set up for it to be a compile time choice between GDI/DWrite.

I will investigate what the current situation upstream is. I know a lot of the font code has been refactored.

(In reply to Bas Schouten (:bas.schouten) from comment #1) > This is odd... skia shouldn't be used by default on windows. This would > occur if Skia was somehow preffed on manually for canvas usage and you were > creating a surface larger than 8192x8192. My DOM fuzzer harness randomizes many graphics prefs. Which pref is relevant here?

I thought it might be useful to explain why I have this use case (DirectWrite without Direct2D), for help deciding if you want to support it. I find that, even with the latest drivers, my card has some weird glitching ever since I upgraded to Windows 8. This glitching only appears in Firefox, not in any other program.* So I disabled acceleration in Firefox. However, I found out that the the GDI implementation of ClearType is deficient, but that, in Windows 8, at least, it finally works properly. For some reason, earlier versions of Windows had a problem with color fringing on light colored fonts. My hypothesis is that Microsoft tweaked ClearType on these fonts in preparation for the Start Screen. (Note, it even works properly with DirectWrite fonts in GDI classic mode--so it's not something to do with pixel boundaries.) I also will report that turning Cairo on in prefs (via gfx.canvas.azure.backends) does seem to fix the PDF.js problem, so that would seem to be the easiest solution. If DirectWrite is on and Direct2D is not, disable Skia as well. Then canvas works as expected. *I've reported this as a bug before, but it could not be reproduced and remains "Unconfirmed."

Upstream skia is apparently going to soon have the ability to compile both GDI and DWrite support, so we'd be able to support this. Until that is done (and we import that version of skia), then disabling skia when DWrite is enabled is probably all we can do.

Sorry to send bugspam, but I have a feeling that anyone else getting the problem I mentioned above will find this page on a Google search, and I want to tell them that I tracked down the problem. It's not with Direct2D but with Azure. Disabling that also fixes the problem, while letting me keep Direct2D acceleration. The relevance to this bug is that there is one less legitimate reason to use the problematic configuration. And if people are disabling Direct2D because it is glitchy, perhaps the real problem is with Azure, and fixing or working around that that would "fix" this bug.

I have a similar usage case to Terrell. I'm running Windows in a VM which is incompatible with Firefox's Direct2D renderer, but GDI font rendering looks decidedly worse than DirectWrite so I have re-enabled it. I had been using this configuration for the past year and a half with no ill-effects until the PDF.js viewer was added. It took me a very long time to narrow down the cause of missing PDF text to this bug and bug 842521. I would suggest forcing GDI rendering if Skia is being used, since Cairo+DWrite has graphics errors. Skia is using a very smooth font rendering method which looks about as good as DWrite to me.