Specific PNG images display with thin solid black border when resized
Reported by
b...@subeta.net,
Jul 22 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 OPR/46.0.2597.46 Example URL: https://codepen.io/cheryllium/live/YxKQOw Steps to reproduce the problem: 1. Use an image tag to include a PNG image on a web page, and resize the image using the width attribute of the tag. Note - This does not happen with all PNG files, only a few. What is the expected behavior? The image displays at correct resized width. What went wrong? The image displays at resized width but with black border. In some sizes it appears to "overflow" the black border slightly. Attached is a screenshot of my codepen as it looks to me as well as the output of opera://gpu. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Unsure Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: stable OS Version: 6.2 (Windows 8) Flash Version: Shockwave Flash 26.0 r0 I am using Opera 46.0.2597.46 (PGO) 64-bit for Windows. This happens with certain specific images and not at all with others. Some of our images are quite old, so I wonder if it may have to do with an older PNG format. Here are some other images it happens with: * https://img.subeta.net/battle/opponents/battleopponent_nependeathicus.png * https://img.subeta.net/battle/opponents/battle_phungis.png * https://img.subeta.net/battle/opponents/challenger_gatekeeper.png Here are some images on the same server it does not happen with. These images are served on the same page on our website: * https://img.subeta.net/battle/opponents/erdoo.png * http://img.subeta.net/battle/opponents/amazonmontre.png * http://img.subeta.net/battle/opponents/daemon.gif
,
Jul 22 2017
I have this on all four images: Opera version 46.0.2597.39 on Arch Linux (x86_64; XFCE)
,
Jul 22 2017
I can also repro on Chrome 59.0.3071.115 on Linux. It doesn't repro on Mac though.
,
Jul 22 2017
Coworker is on Chrome 59.0.3071.115 and operating system Windows 10 Home - Version 1703, Build 15063.483 He sees black borders around all the images, so disregard my earlier comment about resizing the image I suppose.
,
Jul 22 2017
Relying on the PNG file format itself, most of it's photo properties shows the same by Default. Sometimes it's not a huge issue.
,
Jul 23 2017
+scroggo, Are we doing A/B testing or the likes on PNG? Is it possible we aren't filling all pixels and this is the result of the previous memory values? (That question includes for texture memory.) Are we treating Win 8 differently? I just tried on 58.0.3029.110 (Official Build) (64-bit) on MacOS & 59.0.3071.115 (Official Build) (64-bit) (cohort: Stable) on Win 10. Both do not show the black borders. For reference, there is also no black border on Edge 40.15063.0.0 & Firefox 54.0.1 (32-bit) on Win 10.
,
Jul 24 2017
I can't repro on Win10, stable 59.0.3071.115 and Canary 62.0.3164.0 using the example URL in #0.
,
Jul 24 2017
Unable to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest stable #59.0.3071.115 and canary #62.0.3164.0. No black lines are seen around the images. Removing bisect label for now please feel free to add it back if we have consistent repro steps. Thanks!
,
Jul 24 2017
Any additional information for reproducing would be excellent. I can't repro on Mac. I have to assume that the png is such that we pull black pixels when re-sampling on resize.
,
Jul 25 2017
I updated Opera to 46.0.2597.57 (PGO) and can still see the bug. However, I downloaded Chrome Canary and it appears to be fixed there. Screenshot attached. Output of chrome://version says: Google Chrome 62.0.3165.0 (Official Build) canary (64-bit) (cohort: 64-Bit) Revision ebd65246aab3b4b1cb5bd462388344195420078d-refs/heads/master@{#488876} OS Windows JavaScript V8 6.2.3 Flash 26.0.0.143 C:\Users\cheryl\AppData\Local\Google\Chrome SxS\User Data\PepperFlash\26.0.0.143\pepflashplayer.dll User Agent Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3165.0 Safari/537.36 (Same OS as before for both - Windows 8 x64) Despite the images showing correctly, when I click on an image and drag it (as if dragging to open in another program, for instance) the faint copy of the image that gets dragged by my mouse does have the black border. RE: Coworker on windows 10. What would be some information he could add that might be useful? He's not a dev so instructions on how to obtain the information would help if not too much trouble. Thank you.
,
Jul 25 2017
Thank you for providing more feedback. Adding requester "schenney@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 25 2017
I can still repro this on ToT on Linux, but only when running with --disable-gpu.
,
Jul 26 2017
,
Aug 7 2017
The NextAction date has arrived: 2017-08-07
,
Aug 7 2017
,
Aug 9 2017
Unable to reproduce the issue on Windows 10,Mac 10.12.6 & Ubuntu 14.04 using chrome stable#60.0.3112.90 & Canary#62.0.3180.0 for the below URL. https://codepen.io/cheryllium/live/YxKQOw No black borders observed on latest chrome versions. Could you please upgrade chrome to the latest versions & let us know your observations on the same. Note: 1. Able to reproduce the issue on chrome reported version#59.0.3071.115 on only Windows 10. 2. Please find the attached screenshot for reference. Thank you.
,
Oct 12 2017
Since reporter hasn't responded for comment #16, closing this issue for now. bug@ Could you please file a new bug if the issue still exists in latest chrome builds. Thanks! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by ajuma@chromium.org
, Jul 22 2017