Do not clip inside OcclusionTracker.

Do not clip inside OcclusionTracker.

Assume that content-rect is already clipped. This allows us to
early-out from occlusion testing when there is no occlusion.

BUG=276725
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=227133

[alokp, 2013-09-09 22:41:33]

I have not updated the unit-tests yet. I wanted to get early feedback on the
approach.

Not doing clipping inside the occlusion-tracker allows us to early out if there
is no occlusion. This cuts the running time of CalculateRenderPasses by HALF on
simple pages with a single content-layer.

Note that all content-rects passed to the occlusion-tracker is already clipped,
but at the layer level. Occlusion-tracker clips individual tiles, which may
discard more stuff if the layer is not axis-aligned.

[enne (OOO), 2013-09-09 23:37:39]

This approach sounds good to me.  I am quite fine with doing some extra work for
layers with non-axis-aligned clips to have the common case go much faster.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:560:
render_target->render_surface()->content_rect());
I think you shouldn't remove this line.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:630:
render_target->render_surface()->content_rect());
Same here.

[alokp, 2013-09-10 13:31:44]

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:560:
render_target->render_surface()->content_rect());
On 2013/09/09 23:37:39, enne wrote:
> I think you shouldn't remove this line.

I think we should. This is also a form of clipping that has already happened
during CalculateDrawProps. This function should return the same result in both
scenarios:

1. Occluded region is empty. We early-out in this case and do not bother
clipping with anything - clip-rect, target-surface-rect, or screen-rect.

2. Occluded region is non-empty, but does not occlude the given rect. Here if we
clip against the target-surface-rect, you might get a different result.

This was the motivation for not doing any kind of clipping here.

[danakj, 2013-09-10 14:36:37]

I'm curious to see where/how we'll do the clipping now. I think the "HALF"
comparison might be a bit unfair since you did not replace the clipping code
yet, but we'll see! Certainly promising.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:459:
transformed_rect.Intersect(clip_rect_in_target);
Not intersecting with the clip rect means you'll mark things as occluding even
tho they are being clipped. I don't think you can change this function and not
get wrong results. Unless you're planning to do the clipping in
VisibleContentOpaqueRegion()? Or somewhere else?

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:492:
transformed_rect.Intersect(clip_rect_in_target);
same point here

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:703:
unoccluded_region_in_target_surface.Intersect(surface->clip_rect());
This too?

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:719:
contributing_surface_render_target->render_surface()->content_rect());
Why not this?

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:537: *has_occlusion_from_outside_target_surface =
!gfx::SubtractRects(
Have you thought through how we can preserve this bit?

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.h
File cc/trees/occlusion_tracker.h (right):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.h#...
cc/trees/occlusion_tracker.h:50: // |draw_transform| is relative to that.
and |impl_draw_transform_is_known|

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.h#...
cc/trees/occlusion_tracker.h:60: // |draw_transform| is relative to that.
and |impl_draw_t_i_known|

[alokp, 2013-09-10 18:15:46]

Yes it is quite unfair to claim 2x improvement. The big caveat is that this
improvement only for simple cases where there is no occlusion.

I do not think there will be much improvement in the general case.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:459:
transformed_rect.Intersect(clip_rect_in_target);
VisibleContentOpaqueRegion is already clipped. It is computed using
layer::draw_properties::visible_content_rect, which is clipped in
CalculateDrawProps. No?

We are computing enclosed-rect in multiple places, which made me suspicious, but
since we only consider axis-aligned occluding layers, I think this is correct.

Having said that, leaving the clipping here is fine. This is not what slows us
down. Clipping query-rects do because we cannot early out.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:703:
unoccluded_region_in_target_surface.Intersect(surface->clip_rect());
On 2013/09/10 14:36:37, danakj wrote:
> This too?

I have not looked at optimizing surface-rects yet. Focusing on layer-rects for
now. Can we do it in a subsequent patch?

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:719:
contributing_surface_render_target->render_surface()->content_rect());
On 2013/09/10 14:36:37, danakj wrote:
> Why not this?

I am planning to work on surface-rects in a separate patch.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:537: *has_occlusion_from_outside_target_surface =
!gfx::SubtractRects(
On 2013/09/10 14:36:37, danakj wrote:
> Have you thought through how we can preserve this bit?

Sorry I have not looked at occlusion-from-outside closely. Is
occlusion-from-outside the same as clipping or something more?

[danakj, 2013-09-10 18:21:10]

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:459:
transformed_rect.Intersect(clip_rect_in_target);
On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> VisibleContentOpaqueRegion is already clipped. It is computed using
> layer::draw_properties::visible_content_rect, which is clipped in
> CalculateDrawProps. No?

The visible content rect is in content space. So it is clipped to a bounding box
around the actual clip rect, which lives in target space. You can't clip things
in content space and expect them to be tight.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:703:
unoccluded_region_in_target_surface.Intersect(surface->clip_rect());
On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> On 2013/09/10 14:36:37, danakj wrote:
> > This too?
> 
> I have not looked at optimizing surface-rects yet. Focusing on layer-rects for
> now. Can we do it in a subsequent patch?

I think you'll need to handle more than just tile layers anyways, so I don't
expect this should add much effort for you.. but if you like that might be
reasonable. But then you should not be removing the code at line 720, this
function should not be changed at all if you're not changing it fully.

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:537: *has_occlusion_from_outside_target_surface =
!gfx::SubtractRects(
On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> On 2013/09/10 14:36:37, danakj wrote:
> > Have you thought through how we can preserve this bit?
> 
> Sorry I have not looked at occlusion-from-outside closely. Is
> occlusion-from-outside the same as clipping or something more?

It is different. This bit is false if nothing affected the drawing of the target
surface for this quad, such that the target surface texture is complete. In
other words, this is used for surface caching and should be true only if from
the perspective of this quad, the surface texture can be reused forever and
positioned anywhere on screen and remain correct.

If, instead we clipped the quad by something "outside the surface" ie not part
of the surface, then there are invalid pixels in the surface texture that are
not part of the current frame, but may be part of future frames.

This whole feature is disabled right now, but still covered by unit tests, with
some intention of turning it on again. As we continue to work around it, this
gets more awkward..

[alokp, 2013-09-10 20:51:27]

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:459:
transformed_rect.Intersect(clip_rect_in_target);
On 2013/09/10 18:21:10, danakj wrote:
> On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> > VisibleContentOpaqueRegion is already clipped. It is computed using
> > layer::draw_properties::visible_content_rect, which is clipped in
> > CalculateDrawProps. No?
> 
> The visible content rect is in content space. So it is clipped to a bounding
box
> around the actual clip rect, which lives in target space. You can't clip
things
> in content space and expect them to be tight.

I do not understand. I am looking at this:
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...

The clipping happens in the target-space and projected back. If draw-transform
preserves axis alignment, why would it not be tight?

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:703:
unoccluded_region_in_target_surface.Intersect(surface->clip_rect());
On 2013/09/10 18:21:10, danakj wrote:
> On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> > On 2013/09/10 14:36:37, danakj wrote:
> > > This too?
> > 
> > I have not looked at optimizing surface-rects yet. Focusing on layer-rects
for
> > now. Can we do it in a subsequent patch?
> 
> I think you'll need to handle more than just tile layers anyways, so I don't
> expect this should add much effort for you.. but if you like that might be
> reasonable. But then you should not be removing the code at line 720, this
> function should not be changed at all if you're not changing it fully.

OK. I will look at them once we resolve all the layer issues.

[danakj, 2013-09-10 20:54:24]

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
cc/trees/occlusion_tracker.cc:459:
transformed_rect.Intersect(clip_rect_in_target);
On 2013/09/10 20:51:27, Alok Priyadarshi wrote:
> On 2013/09/10 18:21:10, danakj wrote:
> > On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> > > VisibleContentOpaqueRegion is already clipped. It is computed using
> > > layer::draw_properties::visible_content_rect, which is clipped in
> > > CalculateDrawProps. No?
> > 
> > The visible content rect is in content space. So it is clipped to a bounding
> box
> > around the actual clip rect, which lives in target space. You can't clip
> things
> > in content space and expect them to be tight.
> 
> I do not understand. I am looking at this:
>
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...
> 
> The clipping happens in the target-space and projected back. If draw-transform
> preserves axis alignment, why would it not be tight?

Yes it would, you're right! But if it is not axis-aligned.. then you need to do
clipping in the target space. The inputs to this function are in content space,
so you can't just use those, or you'll mark occlusion in the target where there
is actually none.

[alokp, 2013-09-10 20:57:36]

On 2013/09/10 20:54:24, danakj wrote:
> https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc
> File cc/trees/occlusion_tracker.cc (left):
> 
>
https://codereview.chromium.org/23708021/diff/1/cc/trees/occlusion_tracker.cc...
> cc/trees/occlusion_tracker.cc:459:
> transformed_rect.Intersect(clip_rect_in_target);
> On 2013/09/10 20:51:27, Alok Priyadarshi wrote:
> > On 2013/09/10 18:21:10, danakj wrote:
> > > On 2013/09/10 18:15:46, Alok Priyadarshi wrote:
> > > > VisibleContentOpaqueRegion is already clipped. It is computed using
> > > > layer::draw_properties::visible_content_rect, which is clipped in
> > > > CalculateDrawProps. No?
> > > 
> > > The visible content rect is in content space. So it is clipped to a
bounding
> > box
> > > around the actual clip rect, which lives in target space. You can't clip
> > things
> > > in content space and expect them to be tight.
> > 
> > I do not understand. I am looking at this:
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...
> > 
> > The clipping happens in the target-space and projected back. If
draw-transform
> > preserves axis alignment, why would it not be tight?
> 
> Yes it would, you're right! But if it is not axis-aligned.. then you need to
do
> clipping in the target space. The inputs to this function are in content
space,
> so you can't just use those, or you'll mark occlusion in the target where
there
> is actually none.

For now we only consider axis-aligned occluders. So a comment with big WARNING
would be OK?

[danakj, 2013-09-10 20:59:41]

> For now we only consider axis-aligned occluders. So a comment with big
> WARNING
> would be OK?
>
> Oh right, the early out! Turn that into a DCHECK then with a comment about
this, and that's fine.  Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[alokp, 2013-09-13 21:38:46]

I got rid of all clipping and added DCHECKs to make sure that the occluded
region is not bigger than what it was before. If any of these DCHECKs fire then
our assumption of Layer::visible_content_rect and Surface::content_rect being
clipped in CalculateDrawProperties is wrong.

The query functions that return unoccluded-rects may report slightly bigger
rects when the given layers are not axis-aligned.

I also looked at occlusion-from-outside bit, and I do not see if anything needs
to change. Everything should work as before. Early out happens when there is no
occlusion, so "has_occlusion_from_outside_target_surface == false" bit is
correct.

PTAL.

[danakj, 2013-09-16 17:29:07]

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:100: if (have_clip_rect)
I don't really understand this change. It's just an intersect, it's not costly.
Have you tried to construct a counter-example that would hit your DCHECK for
this?

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:264: affected_area_in_target.Intersect(
Again, just an intersection. I think there's two ways clipping can come up in
here.

One is clipping the unoccluded region, and that makes sense to move out. The
other is clipping occlusion, and that is really important to not over-estimate
what's occluded. I don't think that can go away. This is the latter here. I
would need to be convinced that this will never lead to us considering something
occluded when it is not.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:549:
unoccluded_region_in_target_surface.Intersect(clip_rect_in_target);
I think I buy that this can go away (and not move elsewhere). I was worried
about partial culling or rotated layers, but we'll have a clip rect defined at
draw time for these quads so that should prevent wasted drawing.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:557: // Treat other clipping as occlusion from
outside the surface.
I'm not sure why you say that the has_occlusion_from_outside_target_surface will
always produce the same results. In the early-out case sure.. but what about
these cases?

For instance, if the render surface is rotated so it's top-left corner is
outside the viewport, and half of this query is outside the viewport in the
top-left corner there.. what is going to set this bool to true so the surface is
known to be incomplete?

Same question for the 2 functions below.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:406: // TODO(danakj): Find a rect interior to each
transformed quad.
Remove this TODO and mention we don't support non-axis-aligned layers relative
to their target because their visible content rect may exceed the bounds of
their actual visible post-clip region in their target.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:421: #ifndef NDEBUG
if (DCHECK_IS_ON()) {

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:429:
DCHECK(clip_rect_in_target.Contains(transformed_rect));
Note that this DCHECK is verifying the clip rect in the target, but it is not
including the viewport in that. I think one could construct a series of render
surfaces such that the visible_content_rect of the layer would end up not
clipped to the viewport, but would be axis-aligned to its target.

Maybe this won't be a problem in the wild, but if we start seeing missing tiles
on non-impl painting around the edge of the viewport.. we'll know why.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:450: 
extra whitespace

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracker.h
File cc/trees/occlusion_tracker.h (right):

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.h:50: // |draw_transform| is relative to that.
draw_transform and impl_draw_transform_is_unknown are relative to that.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.h:60: // |draw_transform| is relative to that.
draw_transform and impl_draw_transform_is_unknown are relative to that.

[alokp, 2013-09-17 00:31:41]

I will send an email to graphics-dev asking if anyone objects to removing
outside-occlusion bit.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker.cc (left):

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:264: affected_area_in_target.Intersect(
I have decided to break this into two patches - one for query function and
another for things that compute occlusion. Lets focus on the query function for
now. This is not slowing us down anyway.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:557: // Treat other clipping as occlusion from
outside the surface.
You are right. I do not see how I can preserve this bit without clipping. Per
our offline discussion, I will see if I can remove this feature as it is not
being used right now.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:450: 
On 2013/09/16 17:29:08, danakj wrote:
> extra whitespace

Done.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracker.h
File cc/trees/occlusion_tracker.h (right):

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.h:50: // |draw_transform| is relative to that.
On 2013/09/16 17:29:08, danakj wrote:
> draw_transform and impl_draw_transform_is_unknown are relative to that.

Done.

https://codereview.chromium.org/23708021/diff/26001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.h:60: // |draw_transform| is relative to that.
On 2013/09/16 17:29:08, danakj wrote:
> draw_transform and impl_draw_transform_is_unknown are relative to that.

Done.

[danakj, 2013-09-17 15:24:15]

Thanks, this looks fine. Could you include some perf numbers in the CL
description? As I said I'd like to not break the surface caching stuff horribly
unless we can commit to removing it, so I'd like to block this change on
removing surface caching (or finding a way to preserve that bit).

[alokp, 2013-10-02 21:59:26]

Dana: This is ready for review again. RenderSurface caching was deleted in
r226146.

All the affected unittests pass again. Tests that were specifically testing
clipping of the query-rect have been deleted. For other tests query-rect was
adjusted to be contained inside the visible-content-rect.

[danakj, 2013-10-03 21:33:14]

LGTM

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:675: // Treat other clipping as occlusion from
outside the target surface.
What is your plan for contributing surfaces next?

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker_unittest.cc (right):

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker_unittest.cc:1250: // These rects are occluded except
for the part outside the bounds of the
Update comment

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker_unittest.cc:1260: // These rects are occluded except
for the part outside the bounds of the
Update comment

[alokp, 2013-10-03 23:06:30]

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker.cc (right):

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker.cc:675: // Treat other clipping as occlusion from
outside the target surface.
On 2013/10/03 21:33:15, danakj wrote:
> What is your plan for contributing surfaces next?

We should be able to get rid of clipping here as well - not for performance
reason but for consistency. I think it should not affect anything because
RenderSurface::content_rect is also clipped. However I do not yet fully
understand how it interacts with filters. I will need to study it further.

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker_unittest.cc (right):

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker_unittest.cc:1250: // These rects are occluded except
for the part outside the bounds of the
On 2013/10/03 21:33:15, danakj wrote:
> Update comment

I think we should just delete this comment. It does not make sense anymore. We
are now just testing if OcclusionTracker::Occludedlayer returns correct result
for the given occlusion and content-rect.

[danakj, 2013-10-04 16:33:04]

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
File cc/trees/occlusion_tracker_unittest.cc (right):

https://codereview.chromium.org/23708021/diff/41001/cc/trees/occlusion_tracke...
cc/trees/occlusion_tracker_unittest.cc:1250: // These rects are occluded except
for the part outside the bounds of the
On 2013/10/03 23:06:31, Alok Priyadarshi wrote:
> On 2013/10/03 21:33:15, danakj wrote:
> > Update comment
> 
> I think we should just delete this comment. It does not make sense anymore. We
> are now just testing if OcclusionTracker::Occludedlayer returns correct result
> for the given occlusion and content-rect.

OK

[commit-bot: I haz the power, 2013-10-04 18:48:28]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alokp@chromium.org/23708021/48001

[commit-bot: I haz the power, 2013-10-04 23:26:54]

Change committed as 227133