Closed Bug 1401798 Opened 5 years ago Closed 5 years ago
Crash in wr macos font code (rasterize
_glyph): no Subpixel anti-aliasing, but r != g (1 != 2)
This bug was filed from the Socorro interface and is report bp-e1e8c65e-39e9-45de-9612-0526b0170921. ============================================================= https://hg.mozilla.org/mozilla-central/annotate/a20de99fa3c1/gfx/webrender/src/platform/macos/font.rs#l426 Just happened while watching a video and scrolling through a thread in twitter. Possibly something crashed or triggered a fallback?
This assertion comes from WR@a3c82e93d. :kvark, Any idea for this assertion?
Priority: -- → P2
Unexpectedly colored glyph? Not sure, but in any case those asserts don't serve well for us, since unexpected pixel data is still technically not a showstopper for frame rendering. We should `error!` the observed inconsistencies (accumulated for all pixels, perhaps, instead of per-pixel) instead of the asserts. Someone more familiar with OSX fonts may need to explain how we got those color values mismatching.
I can reproduce this with text-shadows on emoji, such as data:text/html,<html><head><meta charset="utf8"></head><body style="text-shadow: 0px 0px 1px black;">
Argh bugzilla: Posted here: https://github.com/servo/webrender/issues/1747
5 years ago
This assert has been removed in https://github.com/servo/webrender/pull/1754 . For grayscale fonts, we just always use the red component now, without checking whether the green and blue components have the same value.
Assignee: nobody → gwatson
Status: NEW → RESOLVED
Closed: 5 years ago
Depends on: 1402321
Priority: P2 → P1
Hardware: Unspecified → All
Resolution: --- → FIXED
See Also: → https://github.com/servo/webrender/issues/1747
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.