Bug 642589 enabled prefs for specifying Cleartype rendering parameters. However, they are not picked up along all codepaths. It appears that calling DrawWindow on a non-opaque (i.e. default) canvas ignores these parameter settings when rendering. Steps: 1. Download the linked testcase (it needs privs to use DrawWindow) 2. Run latest trunk 3. Set 'gfx.font_rendering.cleartype_params.enhanced_contrast' to 800 4. Restart the browser 5. Open the local copy of the linked testcase Result: the rendering shown in the iframe and the image copy produced via DrawWindow show different Cleartype parameter settings, the copy appears to be using system defaults. Note: setting moz-opaque="true" on the canvas element fixes the problem. My guess is that we simply missed a codepath in bug 642589.

This is deliberate. A canvas is an RGBA buffer, and you can't store component alpha text in that buffer, so we disable subpixel AA for canvas text.

We could try to render with component alpha where the canvas pixels are already opaque, but that's hard and potentially confusing. moz-opaque seems to be an acceptable workaround. I suggest we WONTFIX this.

(In reply to comment #1) > This is deliberate. A canvas is an RGBA buffer, and you can't store > component alpha text in that buffer, so we disable subpixel AA for canvas > text. The issue here is how DrawWindow works, not how Canvas text API's function. The attached screenshot shows that there is clearly subpixel AA text rendered in the DrawWindow case, just not subpixel AA text that respects the Cleartype parameters. I suggest we figure out the cause for this, then decide whether to WONTFIX it.

Ah, sorry. Fair enough.