Scale to DIPs in ppb_graphics2d_impl for proper invalidation

ui/gfx/rect.h

Index: ui/gfx/rect.h
diff --git a/ui/gfx/rect.h b/ui/gfx/rect.h
index 62a1ba3a7a3e7d9fbbb4383fb7480b0c75cf4297..398ff5f3e034111a6c9387d6855e9a23d51916e5 100644
--- a/ui/gfx/rect.h
+++ b/ui/gfx/rect.h
@@ -45,6 +45,11 @@ class UI_EXPORT Rect : public RectBase<Rect, Point, Size, Insets, int> {
 
   ~Rect();
 
+  // Apply scale to a rectangle, taking care in to round coordinates outward so
+  // a rectangle scaled down then scaled back up by the inverse scale would
+  // fully contain the original.
+  void ScaleBounds(float scale);

[sky, 2012/07/17 22:12:12]

rect_base already has Scale(float). Is there a reason that doesn't work?

[Josh Horwich, 2012/07/17 22:53:36]

Yes, that method scales the origin and size independently, and the conversion
float->int occurs with a simple static_cast<int> so it will round down. So if
scale is 0.5 (typical on a 2x density display like a Mac Retina when converting
from device pixels to logical pixels/DIPs) and the rectangle in question has
origin (9, 9) and size (10, 10) we'd want the result to be origin (4, 4) and
size (6, 6) when calculating invalid rects in the lower-res (logical pixel)
coordinate system. Using the existing Scale would result in origin (4, 4) but
size (5, 5) and we'd end up not covering the lower-right line of pixels. :(

I didn't change Scale itself in fear of opening up a few thousand cans worth of
worms.

I moved this here since I thought it might be more generally useful for others -
but I don't feel strongly that it should be here - if you wish I can move it
back into the code that specifically needs it (ppb_graphics_2d_impl.cc in my
case)

+
 #if defined(OS_WIN)
   Rect& operator=(const RECT& r);
 #elif defined(OS_MACOSX)