I ran into this cuz I wanted to know the top controls height for computing a tile size via https://bugs.chromium.org/p/chromium/issues/detail?id=622885. I wanted a stable number that wouldn't change, which it turns out this number is. But it was really fun figuring out that was the case, and I see we pass it around a lot more than we should. Which means it could actually change dynamically one day given the current system, but that'd be weird and probably not intentional and would break using it for tile size.

It is intentional.  iOS Safari has a dynamically changing top controls height and we wanted to leave open the possibility of doing the same thing.  Secondly there are scenarios like devtools emulation where it may be more dynamic.  And I don't think plumbing a constant instead of a variable would be significantly less code.

I agree the DIP backconversion is a problem but the rest is fine.

I recommend making tile size independent of top controls height (always use the size assuming that top controls are hidden) It's quite important for it to match width exactly, but because most pages scroll vertically, a small mismatch there doesn't matter as long as it's stable over time.

Oh, huh. Do you know offhand if the viewport size has the top controls removed from it?

> would be significantly less code.

I agree, but it would be a lot easier to reason about given that it doesn't change. But I guess it's meant to change so it's meant to be thought of that way.

> Oh, huh. Do you know offhand if the viewport size has the top controls removed from it?

It depends.  That is also dynamically specified as part of ResizeParams:

  // Whether or not Blink's viewport size should be shrunk by the height of the
  // URL-bar (always false on platforms where URL-bar hiding isn't supported).
  bool top_controls_shrink_blink_size;


I realize this also may strike you as overcomplicated but we didn't add the complexity casually.  It's more that the problem is more complicated than one's initial intuition of it.

Ya, I was trying to find a way to get a "screen size" that will be stable so that we don't make new tiles every time the top controls changes. How would you recommend doing it? Is there some max size that top controls can be somewhere?

Hm, I was trying to find an easier way than giving a "screen size" to the LayerTreeHost, with the intention to do that eventually.

Maybe I need to do that in the same patch tho.

Hmm, I had to look it up a bit.  Unfortunately, physical_backing_size_/device_viewport_size is not stable.

There are two reasonable ways to get a stable viewport size in physical pixels:
1) OutputSurface::SurfaceSize()
2) (viewport_size + top_controls_shrink_blink_size ? top_controls_height : 0) * device_scale_factor

I actually propose that you take the intersection (min) of those two sizes.  The reason is WebView.  WebView can have the viewport (Android View size) either much larger or much smaller than the OutputSurface size (GL framebuffer size).  Taking the smaller of the two will solve  http://crbug.com/472813  while avoiding introducing the inverse problem for tiny WebViews.

Ok thanks for all the info and help. I'll port this over to 622885.