cc: Add an occlusion perf test with more than 1 opaque layer.

cc: Add an occlusion perf test with more than 1 opaque layer.

In this case add 10 layers. This roughly describes a complex chromeos
desktop environment I hope.

On an N4:
*RESULT occlusion_tracker_time: unoccluded_content_rect_fully_occluded= 13.10741901397705 us
*RESULT occlusion_tracker_time: unoccluded_content_rect_10_opaque_layers= 27.276884078979492 us

R=enne@chromium.org, enne
BUG=

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

[danakj, 2014-02-13 23:52:55]

Seem like a reasonable test?

[enne (OOO), 2014-02-13 23:55:06]

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
File cc/trees/occlusion_tracker_perftest.cc (right):

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:75: DebugScopedSetImplThread
impl(&proxy_);
Should the occlusion tracker test do this?

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:175: typedef LayerIterator<LayerImpl,
This seems like baking in logic from the occlusion culler? Where does this logic
live for real?  Is there a way to call it directly rather than duplicating?

[danakj, 2014-02-14 00:00:52]

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
File cc/trees/occlusion_tracker_perftest.cc (right):

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:75: DebugScopedSetImplThread
impl(&proxy_);
On 2014/02/13 23:55:07, enne wrote:
> Should the occlusion tracker test do this?

Sure, done.

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:175: typedef LayerIterator<LayerImpl,
This is the tree walk in LayerTreeHostImpl. Then I'd be perf testing all of
CalcRenderPasses tho.

[enne (OOO), 2014-02-14 00:03:38]

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
File cc/trees/occlusion_tracker_perftest.cc (right):

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:175: typedef LayerIterator<LayerImpl,
On 2014/02/14 00:00:53, danakj wrote:
> This is the tree walk in LayerTreeHostImpl. Then I'd be perf testing all of
> CalcRenderPasses tho.

Hrm, ok.  Do you think it'd be worth leaving a comment in LTHI to say "Hey, if
you change this, maybe this other test over here needs to change too?"

[danakj, 2014-02-14 00:05:29]

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
File cc/trees/occlusion_tracker_perftest.cc (right):

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:175: typedef LayerIterator<LayerImpl,
On 2014/02/14 00:03:38, enne wrote:
> On 2014/02/14 00:00:53, danakj wrote:
> > This is the tree walk in LayerTreeHostImpl. Then I'd be perf testing all of
> > CalcRenderPasses tho.
> 
> Hrm, ok.  Do you think it'd be worth leaving a comment in LTHI to say "Hey, if
> you change this, maybe this other test over here needs to change too?"

Not really, because this is just how we walk a layer. If we changed that in some
way that was dramatic it would break compiling here. This is basically what all
the occlusion tracker unit tests do also.

[enne (OOO), 2014-02-14 00:07:18]

lgtm

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
File cc/trees/occlusion_tracker_perftest.cc (right):

https://codereview.chromium.org/165413002/diff/50001/cc/trees/occlusion_track...
cc/trees/occlusion_tracker_perftest.cc:175: typedef LayerIterator<LayerImpl,
On 2014/02/14 00:05:29, danakj wrote:
> On 2014/02/14 00:03:38, enne wrote:
> > On 2014/02/14 00:00:53, danakj wrote:
> > > This is the tree walk in LayerTreeHostImpl. Then I'd be perf testing all
of
> > > CalcRenderPasses tho.
> > 
> > Hrm, ok.  Do you think it'd be worth leaving a comment in LTHI to say "Hey,
if
> > you change this, maybe this other test over here needs to change too?"
> 
> Not really, because this is just how we walk a layer. If we changed that in
some
> way that was dramatic it would break compiling here. This is basically what
all
> the occlusion tracker unit tests do also.

Ok ok.

[danakj, 2014-02-14 18:00:50]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2014-02-14 18:01:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/165413002/240001

[commit-bot: I haz the power, 2014-02-14 19:01:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-02-14 19:01:04]

Retried try job too often on android_dbg for step(s) slave_steps
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

[danakj, 2014-02-14 19:07:31]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2014-02-14 19:10:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/165413002/590002

[danakj, 2014-02-15 00:57:20]

Committed patchset #6 manually as r251466 (presubmit successful).