User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

I opened http://farmdev.com/ (complete HTML/assets attached as zip) using Nightly 84.0a1 (2020-11-16) (64-bit) on macOS 10.14.6 Mojave

Actual results:

The font in the header is blurry

Expected results:

It should not be blurry. See attached screenshot in Firefox 82.0.3 where it is not blurry.

This shows the blurry fonts on Nightly 84.0a1 (2020-11-16) using the attached zip of files

This shows how the fonts should look (not blurry) in Firefox 82.0.3 (64-bit) using the attached zip of files

Sorry for the delay in reporting this bug. I noticed it maybe a month ago?

Also, I saw https://bugzilla.mozilla.org/show_bug.cgi?id=1674169 but gfx.e10s.font-list.shared=false had no effect.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

:jfkthame, can you comment to the bug?

I think this is a result of enabling webrender. Setting gfx.webrender.force-disabled to true on Nightly appears to restore the sharper rendering.

The difference is quite noticeable at very large font sizes, but doesn't seem to be an issue at smaller sizes. Does webrender switch to a different font rasterization method at large sizes, possibly?

Ah, this is a result of exceeding the FONT_SIZE_LIMIT defined here: https://searchfox.org/mozilla-central/rev/277ab3925eae21b419167a34624ec0ab518d0c94/gfx/wr/webrender/src/glyph_rasterizer/mod.rs#474-476

So at very large font sizes, we rasterize at the limit and then scale the bitmaps, which results in the blurrier rendering.

Can we do something about this? Perhaps increase the limit, and use a platform-specific value if some platforms have problems with huge glyphs whereas others handle them OK?

As a workaround, I noticed I can add this to fix the blurriness:

#masthead a {
  /* ...other existing styles */
  background-color: #fff;
  background-clip: text;
}

(In reply to Jonathan Kew (:jfkthame) from comment #7)

Ah, this is a result of exceeding the FONT_SIZE_LIMIT defined here: https://searchfox.org/mozilla-central/rev/277ab3925eae21b419167a34624ec0ab518d0c94/gfx/wr/webrender/src/glyph_rasterizer/mod.rs#474-476

So at very large font sizes, we rasterize at the limit and then scale the bitmaps, which results in the blurrier rendering.

Can we do something about this? Perhaps increase the limit, and use a platform-specific value if some platforms have problems with huge glyphs whereas others handle them OK?

Right now this is tuned quite precariously to limit the amount of glyph page bloat in WebRender, and larger values were causing too much for us. Until we integrate Pathfinder or some other path rendering system for WebRender to deal with large glyphs, I would rather not increase any size limits.

I wondered if we could bump the size limit for some less-constrained platforms such as perhaps macOS and desktop Linux, but at the same time mitigate the bloat by quantizing large font sizes. So for large glyphs we'd have some degree of bitmap scaling happening, but nowhere near as blurry as it currently is; but the quantization would mean that we don't end up rasterizing separately for every tiny increment of size (e.g during animation or zooming). Does that sound at all possible?

E.g doing something like this ^^ results in noticeably sharper rendering of the example here, across a wide range of font sizes. WDYT?

(In reply to Jonathan Kew (:jfkthame) from comment #13)

E.g doing something like this ^^ results in noticeably sharper rendering of the example here, across a wide range of font sizes. WDYT?

I am really uncomfortable raising limit at all here, as this means the glyph cache size limit needs to be raised as well to prevent thrashing. Quantization isn't really going to help because these large glyphs even at a single size rapidly eat into the available glyph cache, so it's just going to start thrashing no matter what. 512 would be the absolute largest I would condone, and that was what we already used to be at before I had to reduce it. 1024 would just be waaay too much.

All in all, again, I think the only way to really adequately address this is with either path rendering in WR, or maaaybe punt to a blob image if the performance impact isn't obscene. But raising the font size limit is not a good solution, IMO.

FWIW I think we could probably get away with increasing that limit to 512 on android. Speaking only from the perspective of the renderer thread on android, I'll defer to Lee on the consequences on the glyph cache etc. The real solution to bug 1585713 (the slow zooming on Pixel 2) came from bug 1598380 (fixing our PBO usage) rather than tweaking the max size.

The quantization should already happen whilst zooming or animating through the text run's raster space: https://searchfox.org/mozilla-central/rev/49345a8de9adf7c3ded3b173108d7182d2cea929/gfx/wr/webrender/src/picture.rs#4670

(In reply to Kumar McMillan [:kumar] from comment #8)

As a workaround, I noticed I can add this to fix the blurriness:

#masthead a {
  /* ...other existing styles */
  background-color: #fff;
  background-clip: text;
}

I can't get this workaround to work, nor do I understand how it could circumvent the WebRender font size cap. Any further insights into possible workarounds would be very much appreciated.

For reference, I work at a type foundry. Putting large type onto a web page and having it look good is a core concern for us.

(In reply to Peter Dekkers from comment #16)

I can't get this workaround to work, nor do I understand how it could circumvent the WebRender font size cap. Any further insights into possible workarounds would be very much appreciated.

The work around works by forcing a different path (blob image) to be used for drawing text. Are you sure it doesn't work? It really should.

(In reply to Lee Salzman [:lsalzman] from comment #14)

All in all, again, I think the only way to really adequately address this is with either path rendering in WR, or maaaybe punt to a blob image if the performance impact isn't obscene. But raising the font size limit is not a good solution, IMO.

Punting to a blob image should work fine and should be pretty easy to implement (just return false from nsDisplayText::CreateWebRenderCommands)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #17)

The work around works by forcing a different path (blob image) to be used for drawing text. Are you sure it doesn't work? It really should.

Thank you for clarifying that! After revisiting I can confirm that the workaround does indeed draw crisper outlines. However, the type does seem to then render slightly thicker. And when text is highlighted the effect seems to be lost.

I've attached an image to help illustrate. Note how in the second one from the top the gaps between the glyphs are rendering more narrow—too narrow in this case.

So with the workaround I guess you're getting crisp rendering but it comes at the cost of being true to the font's design. It distorts the font outlines. Depending on the use case this may or may not be acceptable.

I realised that my previously-uploaded image had a Chrome screenshot as a baseline for comparison. Here is an updated image that uses Firefox 82.0.3 as a baseline for comparison instead, which I assume makes more sense!

https://hg.mozilla.org/mozilla-central/rev/35411828d9d3

[Tracking Requested - why for this release]: This is very visible in some cases.

It's been mentioned on Twitter today, and I noticed that the problem appears on beta, but not on release. Should we uplift this?

https://keycode.info/ was the website mentioned on Twitter where this is apparent.

Comment on attachment 9189869 [details]
Bug 1677551 - For large font sizes, let nsDisplayText::CreateWebRenderCommands punt to a blob image instead. r=jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: Large fonts are blurry on macOS
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial patch to just avoid rasterizing huge fonts via webrender, as its result is currently inferior.
• String changes made/needed:

User impact if declined: Large fonts are blurry on macOS

I see this on Linux too BTW :-)

I wish this would have been brought up sooner since we're down to just the RC build for 84 at this point and this fix landed on m-c a week ago, but better late than never I guess.

Comment on attachment 9189869 [details]
Bug 1677551 - For large font sizes, let nsDisplayText::CreateWebRenderCommands punt to a blob image instead. r=jrmuizel

Fairly low-risk fix for a bug getting noticed by a number of users. Approved for 84.0rc1.

https://hg.mozilla.org/releases/mozilla-beta/rev/f6eab42b127d