aura: Clean up transformation confusion for root window bounds
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}
Showing
Please register or sign in to comment