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

cc/layers/render_surface_impl.cc

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/layers/render_surface_impl.h"
 
 #include <stddef.h>
 
 #include <algorithm>
 
@@ skipping 57 matching lines @@
 }
 
 RenderSurfaceImpl::DrawProperties::~DrawProperties() {}
 
 gfx::RectF RenderSurfaceImpl::DrawableContentRect() const {
   if (content_rect().IsEmpty())
     return gfx::RectF();
 
   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));
   if (owning_layer_->has_replica()) {
     drawable_content_rect.Union(MathUtil::MapClippedRect(
         replica_draw_transform(), gfx::RectF(surface_content_rect)));
   } else if (!owning_layer_->filters().IsEmpty() && is_clipped()) {
     // Filter could move pixels around, but still need to be clipped.
     drawable_content_rect.Intersect(gfx::RectF(clip_rect()));
   }
@@ skipping 264 matching lines @@
   RenderPassDrawQuad* quad =
       render_pass->CreateAndAppendDrawQuad<RenderPassDrawQuad>();
   quad->SetNew(shared_quad_state, content_rect(), visible_layer_rect,
                render_pass_id, mask_resource_id, mask_uv_scale,
                mask_texture_size, owning_layer_->filters(),
                owning_layer_to_target_scale,
                owning_layer_->background_filters());
 }
 
 }  // namespace cc