Use case: we need such API for devtools, in order to have pixel snapping overlay even when we're using <canvas> or SVG. In HTML, floating values are permitted, but once an element is rendered the engine obviously round them. At 1ddpx the round is the common one (if the fractional portion of the argument is less than 0.5,the value is rounded to the integer with the lower absolute value; otherwise is rounded to the integer with the next higher absolute value); but it starts to differ with different dppx. For example, 1.1 dppx makes the round happens at 0.8750 px; where 2 dppx have multiple rounded points: at 0.25 px and 0.75 px. At 4 dppx the rounded points seems to be at 0.125 px, 0.375 px, 0.625 px and 75.875 px. I was able to reverse a formula back that was working with multiple of 2, but with fractional dppx it wasn't really pixel snapping. I also thought that it's not a good idea having such rounding logic in two places (platform and client), if something changes about the way we round the values. Therefore it's probably better if we'll have an API that gives to us the Rect / Quads using the coordinates and measure in *physical pixels* that the engine is rendered. The attachment in this bug, shows how the browser round the divs' values differently based on different dppx (you can zoom in/out and/or use a different display with different dppx as well, I tried for instance having 300% of zooming on a retina too). Notice that it seems also that the `getBoundingClientRect()` gives slightly different values sometimes. The same seems to be for `getBoxQuads()`. For example, having 0.025 returns 0.03334045410156 from the API; and 0.0750 returns 0.08332824707031.

Brad, I'm assigning this bug to you since we discussed previously together, and you said you will take a look. Feel free to change product / component / subject if I didn't get them right! Thanks!

Yep, I'll figure this out.

I'm not actively working on this anymore. Taking myself off the bug.