Issue 581797  has been merged into this issue.

Huh! I'm surprised it's not even/odd.

At 1.5x, it seems like it's % 3, bizarrely. (Alt-Space, S, Ctrl-Arrow to confirm)

At 2x it's even/odd, which is a bit less wacky.

Gathered some data at different dsfs: https://docs.google.com/spreadsheets/d/1Rs4qlfKKtcRBT4wSqx057O_D-tSRmvPdCqmDfiizeAs/edit?usp=sharing

It's clearly periodic based on the pixels=>dips conversion remainder, likely because content width is in integral dips (I think?)

But it's not just the width. I guess there's some offset from the left also related to dsf.

I think the correct fix is to only allow window sizes that will result in an integral content window size in WM_SIZING. (It looks like Mac does the equivalent of that, or maybe the OS does it).

But I'm still not certain how to calculate that width.

Obsessiveness triumphed, and I figured out what's wrong here.

It's "just" that the client area needs to be an integral multiple of the DSF. (The rects above were looking at the window rect which was confusing.)

There's sort of two different things at play here:

1. The client area (pixels) needs to be a *multiple* of the DSF so that when blink's size is set to an integral number of dips it can match.

2. The client area (pixels) needs to be an *integral* multiple of the DSF because the window size can't be a fraction, of course.

This means:
At dsf=1.5x, width needs to be % 3.
At dsf=2x, width needs to be % 2
At dsf=1.75x, width needs to be % 7.
At dsf=2.5x, width needs to be % 5.
At dsf=πx, still calculating.

(I think the multiple required is... the numerator of the DSF expressed as a reduced improper fraction (?) Maybe there's a clearer way to express/calculate that.)

https://codereview.chromium.org/1935883002/ fixes it during sizing, yay! But I need to do something at initial window creation time too. (I have to use WM_SIZING rather than WM_WINDOWPOSCHANGING to handle resizes on the left/top, I think.)

7 pixels is a lot! Did you try not forcing the size to change, but rounding up how big we think the client area is? This would result in not seeing part of the painting, but that seems better than forcing to sizes that need to change based on scale factor.

I don't think that's a good idea, we're just going to end up with different weird artifacts. 7 pixels isn't really that much in hidpi.

Can't users type in any scale factor, that may not not map nicely at all to an integer?

Only with a command line flag, not in normal use that I know of. Windows 10 only does 0.25 increments.

I guess instead of calculating, I could only apply the clamp only for a known set of scales? Would just be a table of 1.25-3.5 by 25, and then if someone typed in a weird one manually, they'd just still have the black line artifact.

Am I wrong in thinking the real long-term fix here is for views to do all its layout in pixels instead of dips (or, equivalently, use dips but have them be non-integral so that they can convey sub-dip precision), so the content area can take on any integral pixel size at any scale factor?

For example, even if you fix the size to be an integral dip size, you also need to do similarly with the window position.  The position issue results in problems everywhere we convert back and forth between native screen coordinates in pixels and dip-based coordinates; for example, the omnibox dropdown content can be mis-positioned because it's placed absolutely in screen coordinates that go through this conversion.

And all these are just hacks to get around the precision loss issue.  Long term, presumably, we need to address that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e94bb783688613f83f8ba7c6a9b006e751f28aa3

commit e94bb783688613f83f8ba7c6a9b006e751f28aa3
Author: jbauman <jbauman@chromium.org>
Date: Mon Aug 22 19:46:51 2016

Use enclosing rect to find WindowTreeHost size.

This was using the floored size, so with fractional device scale factors
the right and bottom pixels sometimes aren't drawn. The resulting black
area looks ugly with opaque windows (e.g. with a theme on the browser
window).

BUG= 607993 

Review-Url: https://codereview.chromium.org/2263453002
Cr-Commit-Position: refs/heads/master@{#413515}

[modify] https://crrev.com/e94bb783688613f83f8ba7c6a9b006e751f28aa3/ui/aura/BUILD.gn
[modify] https://crrev.com/e94bb783688613f83f8ba7c6a9b006e751f28aa3/ui/aura/window_tree_host.cc
[add] https://crrev.com/e94bb783688613f83f8ba7c6a9b006e751f28aa3/ui/aura/window_tree_host_unittest.cc

Is this fixed? It looks fixed to me. If it actually isn't feel free to reopen.

Yeah, lgtm. Thanks John!

 Issue 462857  has been merged into this issue.