1420648 - Fuzzy emoji images in "Add emoji" panel on Twitter

Status: RESOLVED FIXED

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

Description

[Asif Youssuff]

Attachment: twitter-emoji-bad.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171125220341

Steps to reproduce:

In about:config:
– set “gfx.webrender.enabled” to true,
– set “gfx.webrender.blob-images” to true,
– if you are on Linux, set “layers.acceleration.force-enabled” to true.

1. Login to Twitter
2. In "What's happening?" input area, click on "Add emoji" smiley icon
3. Observe emoji inside of panel


Actual results:

Emoji images are fuzzy.


Expected results:

Emoji images should be sharp as previously.

Comment 1

[Asif Youssuff]

Attachment: twitter-emoji-good.png

Comment 2

[Asif Youssuff]

 8:37.28 INFO: No more inbound revisions, bisection finished.
 8:37.28 INFO: Last good revision: f9122f1e3ab957ba73c436a98fc7fce38606d5a3
 8:37.28 INFO: First bad revision: 889fcba58af7ffc9fbfc8dbade70a6ed24595bac
 8:37.28 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f9122f1e3ab957ba73c436a98fc7fce38606d5a3&tochange=889fcba58af7ffc9fbfc8dbade70a6ed24595bac

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

WFM but I do see it gets decoded at two sizes, 72x72 and 35x35. It may have somehow used or stuck with the downscaled version when it should have switched to the native version.

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

(In reply to Andrew Osmond [:aosmond] from comment #3)
> WFM but I do see it gets decoded at two sizes, 72x72 and 35x35. It may have
> somehow used or stuck with the downscaled version when it should have
> switched to the native version.

Got it to reproduce with the same regression range after adjusting some display settings.

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

Attachment: 0001-Bug-1420648-Ensure-WebRender-computes-the-snapped-im.patch

Looks like bug 1183378 comment 27 has come back to haunt me. Duplicating the logic exactly causes us to round slightly differently sometimes, and has a material impact on twitter smilies. 18x18 is much worse than 18x17 or 17x18.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=68b32fc3db0013050bc7a7fc3134f705588d2e7f

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

Comment on attachment 8933295 [details] [diff] [review]
0001-Bug-1420648-Ensure-WebRender-computes-the-snapped-im.patch

Mea culpa.

Comment 7

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8933295 [details] [diff] [review]
0001-Bug-1420648-Ensure-WebRender-computes-the-snapped-im.patch

So we are basically duplicating gfxContext::UserToDevicePixelSnapped and ComputeSnappedImageDrawingParameters here. If there is no better way of doing this can we get a comment in both those places mentioning this so that any bug fixes to those functions also fixes nsLayoutUtils::ComputeImageContainerDrawingParameters. And a comment(s) in nsLayoutUtils::ComputeImageContainerDrawingParameters for vice versa.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4f88eb1c54fb
Ensure WebRender computes the snapped image decode size the same as the fallback path. r=tnikkel

Comment 9

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/4f88eb1c54fb