Closed Bug 1420648 Opened 4 years ago Closed 4 years ago

Fuzzy emoji images in "Add emoji" panel on Twitter

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected

People

(Reporter: yoasif, Assigned: aosmond)

References

Details

(Keywords: nightly-community, regression, Whiteboard: [wr-mvp])

Attachments

(3 files)

Attached image 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.
Attached image twitter-emoji-good.png
 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
Has Regression Range: --- → yes
Has STR: --- → yes
Whiteboard: [wr-mvp] [triage]
Priority: -- → P3
Whiteboard: [wr-mvp] [triage] → [wr-mvp] [triage][wr-reserve-candidate]
Whiteboard: [wr-mvp] [triage][wr-reserve-candidate] → [wr-reserve]
Blocks: 1183378
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.
(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.
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Priority: P3 → P1
Whiteboard: [wr-reserve] → [wr-mvp]
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 on attachment 8933295 [details] [diff] [review]
0001-Bug-1420648-Ensure-WebRender-computes-the-snapped-im.patch

Mea culpa.
Attachment #8933295 - Flags: review?(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.
Attachment #8933295 - Flags: review?(tnikkel) → review+
Pushed by aosmond@gmail.com:
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
https://hg.mozilla.org/mozilla-central/rev/4f88eb1c54fb
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
QA Whiteboard: [good first verify]
See Also: → 1453747
Depends on: 1510306
You need to log in before you can comment on or make changes to this bug.