cc: Use FilterOperations::MapRect in RenderSurfaceImpl::DrawableContentRect.

cc/layers/render_surface_impl.cc

Index: cc/layers/render_surface_impl.cc
diff --git a/cc/layers/render_surface_impl.cc b/cc/layers/render_surface_impl.cc
index ed036f3933ea188c7d371e2f5244c6d9ef2f1809..d2e5a73673327eb2d5661cf9541ef856e61296aa 100644
--- a/cc/layers/render_surface_impl.cc
+++ b/cc/layers/render_surface_impl.cc
@@ -75,9 +75,8 @@ gfx::RectF RenderSurfaceImpl::DrawableContentRect() const {
 
   gfx::Rect surface_content_rect = content_rect();
   if (!owning_layer_->filters().IsEmpty()) {
-    int left, top, right, bottom;
-    owning_layer_->filters().GetOutsets(&top, &right, &bottom, &left);
-    surface_content_rect.Inset(-left, -top, -right, -bottom);

[jbroman, 2016/05/27 17:43:48]

Output of the test before this patch:

[ RUN      ] LayerTreeHostCommonTest.DrawableContentRectForReferenceFilter
../../cc/trees/layer_tree_host_common_unittest.cc:1439: Failure
Value of: child->render_surface()->DrawableContentRect()
  Actual: -50.000000,-50.000000 75.000000x75.000000
Expected: gfx::RectF(50, 50, 25, 25)
Which is: 50.000000,50.000000 25.000000x25.000000
[  FAILED  ] LayerTreeHostCommonTest.DrawableContentRectForReferenceFilter (7
ms)

Note that not only was the previous rect large, but it didn't even enclose
(50,50) 25x25, because GetOutsets was asking for the reverse mapping from Skia,
even though (I believe) the forward mapping is desired here.

+    surface_content_rect =
+        owning_layer_->filters().MapRect(surface_content_rect, SkMatrix::I());

[Stephen White, 2016/06/01 17:17:38]

Er, wait. Shouldn't we be using the filters_scale here for the matrix?

(E.g., for hiDPI?)

[jbroman, 2016/06/01 19:38:00]

I don't think so; I'd expect that the scale of filter dimensions (blur radii,
etc.) would be in the coordinate space of the surface_content_rect (and, of
course, the existing outsets were not accounting for filters_scale).

I'd expect the MathUtil::MapClippedRect(draw_transform(), ...) to deal with the
appropriate transformations to put the rectangle in target space.

But I admit to being a little out of my depth here.

[Stephen White, 2016/06/01 22:13:12]

It's not the rectangle that's the problem; it's the filter parameters. If the
rectangle is in device space (e.g., has hiDPI 
applied), then the filter parameters have to be transformed to device
space via a scale in the matrix to apply hiDPI to the filter 
parameters as well.

It's entirely possible that this path has bugs wrt hiDPI; IIRC, it's
only relevant when nested filters are applied (e.g., filters on 
both parent and child layers). Unless I'm misremembering when this
is used...

Anyway I'm fine if you want to land this and investigate the HiDPI
case separately, since as you say, the old code path wasn't applying 
the scale either.

[jbroman, 2016/06/06 17:16:59]

Yes, but the rectangle isn't in device space yet at this point; I think it's the
MapClippedRect below that sends it to device space.

   }
   gfx::RectF drawable_content_rect = MathUtil::MapClippedRect(
       draw_transform(), gfx::RectF(surface_content_rect));