White one pixel line seen during pinch zoom |
||||||||
Issue descriptionChrome Version: 55.0.2883.91 (official Build) OS: Android 7 and Android 6 What steps will reproduce the problem? (1) Open link http://gg.gg/4d2mh (2) Enable "force enable zoom" in accessibility settings. (3) Perform pinch zoom on images present in the webpage. What is the expected result? Images in webpage are displayed correctly. What happens instead? White single pixel line seen in some of the images present in the website. Its clearly seen performing pinch zoom on image 6 and image 7 of this particular link. Additional Info: White line seem to appear when content_scale ( in tile_manager during Playback) is fractional value and disappears when content_scale is an integer. Comics in the webpage are displayed using <ul> list elements and white line appear at the end of each <li> element. Issue is clearly visible when end of <li> overlaps an comic image (for eg. 6th and 7th image in above link - attached images). Also issue happens in latest canary build/beta and does not seem to be a regression.
,
Feb 8 2017
Can reproduce it with my retina mac pro, with device mode enabled. The layer border does show that the white pixels are at the edge of one tile. It seems to be related to coverage computing in PictureLayerTilings. enne@ and danakj@: can you verify that?
,
Feb 8 2017
,
Feb 8 2017
,
Feb 8 2017
,
Feb 8 2017
trchen, can you take a look at this?
,
Feb 8 2017
A couple of observations: - The white line that appears is not on tile boundaries (it's within one tile). - Disabling cc image decodes does not fix the issue. - Safari has the same issue. I think the issue here is that we get two images that fall on a fraction of a pixel, which makes it very difficult to do the right thing assuming the browser is antialiasing. For example, assuming the image is 100% blue and the background is 100% white and the images "touch" at 0.5 of a pixel: - The background is drawn on the pixel, making it 100% white - The first image is drawn, it's covering the pixel 50%, so it's blended with what is already there (100% white) to produce 50% blue 50% white - The second image is drawn, it's covering the pixel 50%, so it's also blended with what is already there (50% blue 50% white) to produce 75% blue 25% white. Assuming that this is the issue, Skia/CC would have to check all of the commands that cover the pixel in order to figure out what color it should be, and I don't really think that's feasible.
,
Feb 9 2017
Given Safari has the same issue I'm removing bisect. The underlying issue may well be the lack of sub-pixel layout in tables, but we're not fixing that until LayoutNG.
,
Feb 9 2017
Yeah, I've wontfixed things like this in the past, like 431480.
,
Sep 14
I'm leaving the team thus re-assigning. Hey Stephen, could you help me find an appropriate owner for this (or close as WontFix?)? I believe this is related to anti-aliasing. Basically there will always be a seam in between antialiased edges unless there is an overlap. The only feasible solution I can think of is to use MSAA.
,
Sep 14
,
Sep 17
In the general case, the solution here is to ship use-zoom-for-dsf in my opinion. This will let us lay these things out at the correct scale. I disagree about MSAA. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by e...@chromium.org
, Feb 2 2017