Mozilla Slack Instance's :thank-you: emoji-reaction is distorted in Firefox (with downscaling and `image-rendering: crisp-edges`)
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(7 files)
screenshot in Firefox (showing the emoji inline in a message, and as a smaller reaction)
I just noticed that Mozilla's :thank-you: emoji looks pretty-broken in Firefox, in Mozilla's slack instance, at least when viewed in on a system with traditional 100% pixel scaling. (It's probably a bit less-bad on retina displays like on a MacBook Pro.)
The issue is visible when :thank-you: is used directly in messages, and it's especially-true when it's used as a reaction. Essentially, the more downscaling involved, the worse it is.
It looks like slack is specifying image-scaling:crisp-edges on these images, which means we're using nearest-neighbor sampling, which produces crisp edges on upscale, but it often unfortunately produces broken-looking results when downscaling.
I think image-rendering:pixelated is really what they should be using here -- that's specced as behaving better than crisp-edges for downscaling -- but it looks like that doesn't help us out, because our pixelated implementation is simpler than what the spec calls for; see bug 1728831 and bug 1731134.
Screenshots coming up, showing our rendering vs. Chrome. Chrome's rendering looks much nicer, though it's not an apples-to-apples comparison since Chrome rejects crisp-edges. If I specify pixelated instead to make it an apples-to-apples comparison, their rendering gets similarly-gross to ours. However, if we fixed bug 1731134 and matched the spec, then I think the expected-result is that we would look the same as Chrome looks right now (i.e. we'd look as if the value weren't specified at all).
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 1•3 years ago
|
||
|
|
Reporter | |
Comment 2•3 years ago
|
||
Here's a screenshot where I've scaled it up 8x. Notice:
- In the larger "TY" emoji (inline in a message), the vertical-bar portion of the
Yis shifted to the left, with respect to the upper "v" part. - In the smaller "TY" emoji (reaction to a message), the upper part of the
Yis squished and distorted so that it's hard to recognize it as a Y.
|
|
Reporter | |
Comment 3•3 years ago
|
||
|
|
Reporter | |
Comment 4•3 years ago
|
||
|
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 5•3 years ago
|
||
|
|
Reporter | |
Comment 6•3 years ago
|
||
IMO Chrome's rendering (with image-rendering:pixelated added) is similarly-gross to our rendering.
Really, this is a combination of two things:
-
a WebCompat bug, where Slack is sending CSS that Firefox supports and Chrome does not, which makes things actively worse when it's honored (at least in the case of this particular image).
-
a rendering bug, where ideally this CSS (or rather, "pixelated" which is what they want to be using) should not make things worse, if we implemented what the spec says. That's bug 1731134.
|
|
Reporter | |
Comment 7•3 years ago
|
||
Here's the graphic itself that we're having to scale. It's hosted at https://emoji.slack-edge.com/T027LFU12/thank-you/9f6f78820357f016.png .
It's 64px by 64px, though it's being displayed at 22px by 22px (in messages) and 16px by 16px (in reactions); so there's a good deal of downscaling going on.
|
|
Reporter | |
Comment 8•3 years ago
•
|
||
Here's a standalone testcase.
In Firefox, the last two images on each row look a bit gross (similar to the earlier Firefox screenshots).
In Chrome, the last image on each row looks a bit gross (similar to the earlier Chrome image-rendering:pixelated screenshots). (The second image looks the same as the first, simply because Chrome doesn't support crisp-edges.)
Ideally, if we fix bug 1731134, then the third image in each row (the pixelated) should look just as good as the first one, because we'd be doing what the spec says -- scaling to the nearest exact multiple (which is 1:1) and then scaling down smoothly from there. (And ideally, Slack would be using pixelated rather than crisp-edges, to theoretically request that behavior, with pixelated-upscaling and nice-and-smooth downscaling.)
| Comment hidden (advocacy) |
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 10•2 years ago
|
||
...and it seems Slack has now removed this image-rendering styling from their CSS, possibly because they discovered this issue themselves (or folks reported this to them).
I'm not seeing the issue (visually) on Slack anymore, and when I inspect the same .c-emoji img elements in a sample Slack posting, I'm not seeing any image-rendering CSS declarations.
So, following up on comment #6:
Really, this is a combination of two things:
- a WebCompat bug, where Slack is sending CSS that Firefox supports and Chrome does not, which makes things actively worse when it's honored (at least in the case of this particular image).
This part now seems to be fixed (via Slack removing the CSS in question).
- a rendering bug, where ideally this CSS (or rather, "pixelated" which is what they want to be using) should not make things worse, if we implemented what the spec says. That's bug 1731134.
This is of course still an issue, but (as noted) it's tracked separately in bug 1731134, and we don't benefit from having two bugs open to cover the same thing.
Hence, resolving as WFM.
|
|
Reporter | |
Comment 11•2 years ago
|
||
FWIW I just noticed the same approximate issue on a Time article (with a downscaled sponsor logo at the top of the article).
I filed that as https://github.com/webcompat/web-bugs/issues/104851 with suggested outreach to remove the CSS in question, since they almost certainly just want the default downscaling behavior.
Description
•