Scaled parent element background bleeds behind inline-block element
Reported by
abygailg...@gmail.com,
Apr 12 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Example URL: https://jsfiddle.net/d73ec8aj/72/ Steps to reproduce the problem: 1. Create a container block element with a 'transform: scale(X); padding: 0; background-color: red;' on it where X is not 1. 2. Add an 'display: inline-block; margin: 0; background-color: white;' element to the container with a width < 100% 3. Make sure the sizes of the blocks can't be divided by the scale (use something like 'transform: scale(0.87);') 4. View the page on a non-retina screen (both Windows & Mac tested) What is the expected behavior? The inline-block element is positioned to the edge of the container block. What went wrong? A half-pixel line from the container area is visible beneath the inline-block element. 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? Yes Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.13.4 Flash Version: It's kind of like there two bugs, but not exactly: https://bugs.chromium.org/p/chromium/issues/detail?id=429677 https://bugs.chromium.org/p/chromium/issues/detail?id=257946 The JSFiddle (https://jsfiddle.net/d73ec8aj/72/) was created after a customer reported strange gaps between his inline-block elements (for a project that is not publicly avaibable yet). With some withs the problem doesn't occur, so it appears to be a scaling/rounding error in the paint. The problem also doesn't occur when viewed on a Retina screen. The problem occurs in Chrome and Safari., the JSFiddle supplied does work in Firefox, Internet Explorer 11 and Edge.
,
May 2 2018
The transform is a non-composited transform because it is 2D. The overflow clip bounds after transform becomes fractional, and we do apply AA clips, that resulted in the bleeding. As far as I know, Firefox implements snapping at rasterization, so fractional sized rects gets snapped to physical pixels, but it could still be subject to bleeding if the transform involves rotation. Blink chose not to have raster snapping because it opens a different can of worm. For example, square can become non-square due to different snapping direction in X/Y axis, identical boxes can end up rastered differently due to snapping. I'm not saying either choice is superior than the other, but this is the trade-off we made. Personally I prefer to render with MSAA, which will have nice anti-aliased edges while not have bleeding problem, but MSAA is too expensive on memory for many of our users. I'm afraid there is not a lot I can do to improve this bug. |
||
►
Sign in to add a comment |
||
Comment 1 by schenney@chromium.org
, Apr 12 2018Owner: trchen@chromium.org
Status: Assigned (was: Unconfirmed)