Closed Bug 1420648 Opened 4 years ago Closed 4 years ago
Fuzzy emoji images in "Add emoji" panel on Twitter
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.
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
4 years ago
Priority: -- → P3
Whiteboard: [wr-mvp] [triage] → [wr-mvp] [triage][wr-reserve-candidate]
Whiteboard: [wr-mvp] [triage][wr-reserve-candidate] → [wr-reserve]
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.
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 firstname.lastname@example.org: 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
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.