Margins are exposed when a continuous image is displayed.
Reported by
dotol...@gmail.com,
Feb 12 2018
|
||||||||||||||||||
Issue descriptionExample URL: http://m.comic.naver.com/webtoon/detail.nhn?titleId=557672&no=223 Steps to reproduce the problem: 1. Launch Chrome browser app 2. Move to url. (http://m.comic.naver.com/webtoon/detail.nhn?titleId=557672&no=223) 3. Just scroll down. What is the expected behavior? Images are expose without margins or white line. What went wrong? Margins are exposed when a continuous image is displayed. Device screen resolution : 1440 x 2960 (18.5:9) * http://m.comic.naver.com/webtoon/detail.nhn?titleId=557672&no=223 * http://m.webtoon.daum.net/m/webtoon/viewer/48062 Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 64.0.3282.137 Channel: stable OS Version: Android 7.0.0 Flash Version:
,
Feb 13 2018
Tried this on a Pixel 2, Chrome 64.0.3282.137. I do see a small bar on the right, but it's the scroll bar. Are you sure you're not seeing a scroll bar?
,
Feb 13 2018
I apologize for the lack of explanation. Please disregard the white areas in the right flank. The problem is the thin white horizontal line in the middle of the attached screenshot.
,
Feb 13 2018
Thank you for providing more feedback. Adding requester "rtoy@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
,
Feb 15 2018
I notice the line in the screenshots but can't reproduce it locally.
dotoli21@, could you confirm a few things:
1) Does you see this in other browsers/apps?
2) Does this happen on multiple pages when viewed in Chrome or just the links above?
3) Does it occur only on images? e.g., paste this into your url bar:
data:text/html,<!DOCTYPE html><style> body {background-color: black;} </style>
This displays a fully black page. Does that show the issue?
Assuming this is an issue in Chrome, could you also provide the device you're using and paste the results in chrome://gpu
,
Feb 19 2018
1) Does you see this in other browsers/apps?
No. In case, Firefox app v58.0.2 looks fine. I can't find white horizontal line.
(See attached image file #1, #2)
2) Does this happen on multiple pages when viewed in Chrome or just the links above?
It occur every continued images.
3) Does it occur only on images? e.g., paste this into your url bar:
data:text/html,<!DOCTYPE html><style> body {background-color: black;} </style>
Yes. I tried but has been occured.
,
Feb 19 2018
This looks like a tiling artifact. Tentatively triaging this as a compositor bug.
,
Feb 20 2018
This looks like a Skia rasterization issue. hcm, can you triage? Was able to repro locally on my Pixel running 64.0.3282.137 in both gpu and software rasterization modes. Attaching some screenshots from my pixel (remote debugging) with layer borders turned on. It looks like the white border is not between tiles (light blue lines), but is between divs (2nd div selected in the second picture). The li just have an img in them, so it seems like while they're adjacent at scale=1, at some higher scale applied to the Skia canvas while rastering, they are no longer adjacent and have cracks between them.
,
Feb 21 2018
Might also be image scaling pulling in boundary pixels. Doesn't repro on Desktop at scale or in device emulation on desktop.
,
Feb 26 2018
was out last week- looking now.. +reed +fmalita for ideas
,
Feb 26 2018
,
Feb 26 2018
I can repro on desktop Linux, with the device emulator + specified resolution + some fractional zoom - see attached. My initial guess: this is plain background bleed due to edge anti-aliasing. We're drawing images with anti-aliased paints, so unless the dest rect is pixel-snapped perfectly in device space, the background will bleed through edges. IIRC we are trying hard to pixel-snap the world, but it requires knowledge of the global CTM. Unfortunately that is only available with kEnableUseZoomForDSF turned on. AFAICT kEnableUseZoomForDSF is not yet enabled on Android (*) - so that + fractional device scale factors present on some devices may explain the behavior. * https://cs.chromium.org/chromium/src/content/public/common/use_zoom_for_dsf_policy.cc?rcl=702e84f69e4d6741867d4ab4465c49a67fde601f&l=28
,
Feb 27 2018
Simpler Linux repro: --force-device-scale-factor=1.45 --enable-use-zoom-for-dsf=false Certainly seems related to (the absence of) kEnableUseZoomForDSF, so I'm growing more confident in the theory above.
,
Feb 27 2018
|
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by sandeepkumars@chromium.org
, Feb 13 2018