1505459 - [WebRender] Bold fonts rendered looks awful with WebRender enabled

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[nayinain]

Attachment: about:support

e.g. https://www.qq.com/

WebRender Enabled:
https://bug1492673.bmoattachments.org/attachment.cgi?id=9023299
WebRender disabled:
https://bug1492673.bmoattachments.org/attachment.cgi?id=9023300


Sorry for my bad English.

Comment 1

[Lee Salzman [:lsalzman]]

So I tried to reproduce this locally but I couldn't see to get things to differ at all.

But looking at the screenshots closely, you can see that some of the kanji are not only bolder, but just actually different, even in the non-bold ones. So it looks like somehow, with WR enabled, when we request the font family here (presumably "Microsoft Yahei"), we are getting another font? Or are we somehow getting a different bitmap strike or some such? Ideas Jonathan?

Comment 2

[Lee Salzman [:lsalzman]]

I asked other people to try to reproduce this, but they haven't been able to. Can you use the right-click menu on the text to go to "Inspect Element", then go to the "Fonts" tab, and see what font it is actually using? Also, do you have any overrides or non-default settings with respect to ClearType or fonts in general?

Comment 3

[Jonathan Kew [:jfkthame]]

To reproduce, you may need to zoom out so that the effective font size (in device-pixel terms) is smaller; I think the OP's screenshots are from a low-dpi display. On my laptop (where devicePixelRatio is 2.0 by default), I can see similar issues if I zoom out to 50%, but at 100% it looks OK.

What I think may be going on is that with WR enabled, we're not getting the correct hinting and/or antialiasing mode used, and at small font sizes this becomes increasingly important. Specifically, I think I'm seeing symmetrical smoothing used at small sizes with WR, whereas when WR is disabled, those small sizes get horizontal-only ClearType, and hinting in the vertical axis that snaps horizontal strokes to pixels.

The 'gasp' table in the font should control how different hinting/AA strategies are used at different sizes. Checking the Yahei Bold font, we have

  <gasp>
    <gaspRange rangeMaxPPEM="8" rangeGaspBehavior="14"/>
    <gaspRange rangeMaxPPEM="17" rangeGaspBehavior="7"/>
    <gaspRange rangeMaxPPEM="65535" rangeGaspBehavior="15"/>
  </gasp>

while in the Regular face, it is

  <gasp>
    <gaspRange rangeMaxPPEM="8" rangeGaspBehavior="14"/>
    <gaspRange rangeMaxPPEM="22" rangeGaspBehavior="7"/>
    <gaspRange rangeMaxPPEM="65535" rangeGaspBehavior="15"/>
  </gasp>

So from 8ppem to 17ppem (for Bold) or 22ppem (for Regular), the GASP_SYMMETRIC_SMOOTHING bit is NOT set; and when WR is disabled, I see a distinct change in the rendering at this 17ppem or 22ppem threshold. But it looks to me like with WR enabled, this is being ignored, and symmetric smoothing is applied at all sizes. (I'm also unsure whether the proper grid-fitting is being done under WR.)

Comment 4

[Lee Salzman [:lsalzman]]

This is a bug in dwrote-rs not returning the proper rendering mode from get_recommended_rendering_mode. It will be fixed by https://github.com/servo/dwrote-rs/pull/26

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Lee, can you take a look at the reftest fail/passes in https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=bd13a610a4d7fe3f5cdc7389085fe64e0d9de348 and (preferably) create a patch that updates annotations as needed? Or (less preferably) let me know if the changes are all ok and I can make the patch.

Comment 6

[Lee Salzman [:lsalzman]]

Attachment: fuzz for fixed WebRender DWrote text render mode

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 9024009 [details] [diff] [review]
fuzz for fixed WebRender DWrote text render mode

Review of attachment 9024009 [details] [diff] [review]:
-----------------------------------------------------------------

Landing this over in bug 1506129 with the WR update

Comment 8

[nayinain]

This issue is now verified as fixed in nightly65.0a1(2018-11-18). Thank you.