New issue
Advanced search Search tips

Issue 798223 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

100x CSS translation of small position results in inaccurate painting

Reported by leonger...@gmail.com, Jan 1 2018

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 9901.77.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.97 Safari/537.36
Platform: 9901.77.0 (Official Build) stable-channel caroline

Steps to reproduce the problem:
1. Use a CSS 3d transform to move an element
2. Inspect the element using the developer tools

What is the expected behavior?
The element is painted per the CSS specification, and in the position indicated by the developer tools.

What went wrong?
The element is painted in another position. The element inspector shows the position that would be expected according to the spec, but the actual paint is elsewhere.

Attached screenshot shows an inspection of the element. The line on the left shows where developer tools thinks the element is. This is the correct location. The line on the right is where the element is actually painted.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 62.0.3202.97  Channel: stable
OS Version: 9901.77.0
Flash Version: 

Attached test case produces expected results in firefox 57.
 
test.html
343 bytes View Download
Screenshot 2018-01-01 at 17.28.50.png
5.8 KB View Download
This may be related to rounding of the width of the "b" element. When the width of the "a" element is divisible by 100 with a decimal that is not .5*, the "b" element is painted in the correct position.

*e.g. 
100px = 1px, OK
200px = 2px, OK
450px = 4.5px, OK
460px = 4.59px (?) WRONG
480px = 4.8px WRONG
500px = 5px OK


Components: Blink>Compositing>Transform3D
Status: Available (was: Unconfirmed)
Summary: 100x CSS translation of small position results in inaccurate painting (was: CSS transform results in inaccurate painting )
We might be able to do better with rounding, but re-arranging the computation to reduce rounding artifacts is likely to be very hard. The underlying issue is probably snapping the div location to layout units then scaling afterwards.
Project Member

Comment 3 by sheriffbot@chromium.org, Jan 2

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)
Really should look into this, because it's still happening.

Sign in to add a comment