GitLab

Implementations of GetTransformedRootWindowBoundsInPixels() are
currently applying the inverse of the desired transformation: the root
window transform converts root window pixel coordinates to host pixel
coordinates. This function needs to do the reverse: it takes host pixel
coordinates, and returns root window pixel coordinates.

The reason this was not causing bugs is that in production Chrome OS &
Cast both override this function to throw out the origin of the returned
rect. Setting the origin to zero after transforming corrects for applying
the wrong transformation: the rest of the transformation is a 0, 90, 180,
or 270 degree rotation. Since 0 and 180 degree rotations are
self-inverses, and a 90 degree and a 270 degree rotation have identical
effect on sizes, keeping only the size ensured correct results.

Clean up this confusion by inverting the transformation applied by
GetTransformedRootWindowBoundsInPixels(). This means that the origin of
the transformed rect will automatically be correct (i.e., it will be
zero), except during configuration (because bounds & transform aren't
updated atomically).

We still force the origin to zero to avoid any behavioral change from
roundoff. There are some minor discrepancies related to that:

 - Chrome OS puts the window at origin, and rounds the size down
 - Cast puts the window at the origin, and rounds the size up
 - The default implementation allows arbitrary positioning, and
   takes an enclosing rect

These discrepancies are unchanged in this patch.

Bug: 1019015

Change-Id: I9bb40872be2fc76f04e63350a67965d44b71cc6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1885633Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713223}