Initialize cc::Renderer in vsync

Merge cc initialization paths

Code path between first initialization and recreate on context
lost are merged. Do this by changing the first initialization
behavior to match recreate. Now both are kicked off by the
scheduler and blocks the main thread on the impl thread.

The scheduler is started in output surface lost state and
immediately schedules recreation. This means the first
initialization in thread mode is no longer synchronous.

BUG=233664, 230197
This has been tried many many times.
NOTRY=true

Reverted twice due to breaking WebGLInfobarTest:
Committed in r196480. Reverted in r196509.
Committed in r196708. Reverted in r196790.
Fix for WebGLInfobarTest landed in r197235.

WebViewTest.Shim became flaky on chromeos but was already
flaky without this. Disabled it in r197497.

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

[boliu, 2013-03-25 23:12:02]

Hey James,

This is the initial still incomplete patch to move cc::Renderer::Initialize
inside onTimerTick so that it's called inside draw functor for android webview.
Accomplished by adding a state to OutputSurfaceState and an initialize renderer
action called inside vsync.

Regarding perf regression, I was thinking instead of waiting for the next tick,
we can add something like TimeSource::ForceTick and just shortcut it for
DelayBasedTimeSource.

Does this look like something acceptable?

[jamesr, 2013-03-25 23:16:46]

Holding the main thread blocked until the first vsync is going to be too slow,
if that's what you are trying to implement.  I think a better direction would be
to make renderer initialization asynchronous.

[boliu, 2013-03-27 19:36:28]

James, could you point me some perf tests that would affected by changing code
here? A link to a set of tests on a perf bot would be good.

[boliu, 2013-03-30 01:46:20]

Hey James, could you take a look at the description of this CL and see if the
direction I'm going down is ok? (I guess on Monday)

Now on start up, main thread is no longer blocked until the first vsync, but I
can't really make sure webkit does not start calling methods on LTH before it's
ready. Nothing goes wrong in practice on desktop linux though.

RecreateOutputSurface is still synchronous and has to wait for the next vsync,
because it seemed too hard to make that async.

Do you feel it's worthwhile to add a setting for this behavior given only
webview has this requirement that can potentially have perf impact on all
platforms.

[boliu, 2013-04-01 23:43:04]

On 2013/03/30 01:46:20, boliu wrote:
> Hey James, could you take a look at the description of this CL and see if the
> direction I'm going down is ok? (I guess on Monday)
> 
> Now on start up, main thread is no longer blocked until the first vsync, but I
> can't really make sure webkit does not start calling methods on LTH before
it's
> ready. Nothing goes wrong in practice on desktop linux though.
> 
> RecreateOutputSurface is still synchronous and has to wait for the next vsync,
> because it seemed too hard to make that async.
> 
> Do you feel it's worthwhile to add a setting for this behavior given only
> webview has this requirement that can potentially have perf impact on all
> platforms.

ping! ^^^

[jamesr, 2013-04-02 22:42:08]

Is there something specific you want me to look at?  This looks incomplete, but
I think that's expected.  Here are a few questions:

It doesn't look like the case where the initialization fails on the first try is
handled here, is it?

I don't think we want to have separate paths for creation and recreation, but I
suspect you're still working on unifying those, right?

In this new initialization path the capabilities are not set after the initial
blocking init happens.  Is that OK?  Is anything likely to query the
capabilities early and if so is there any mechanism to prevent that?

[boliu, 2013-04-02 23:57:15]

On 2013/04/02 22:42:08, jamesr wrote:
> Is there something specific you want me to look at?

Just the general direction this patch is going. So mainly scheduler,
scheduler_state_machine, and how it interacts with thread_proxy.

> This looks incomplete, but
> I think that's expected.  Here are a few questions:

Wow, great questions. I'm running into them as I was working through
crashing/failing tests. (Great tests btw)

> 
> It doesn't look like the case where the initialization fails on the first try
is
> handled here, is it?

It would call into LayerTreeHost::OnRendererInitialized(false). It's still
incomplete. So far it's called if Renderer::Initialize fails, but not for
OutputSurface::BindToClient. Also it should trigger output lost path in
scheduler.

> 
> I don't think we want to have separate paths for creation and recreation, but
I
> suspect you're still working on unifying those, right?

Currently they are the same in schduler/state_machine, but diverges in between
LTH and Proxy, since recreate is sync.

Looking at the code again, I'm now slightly confused about what triggers a
recreate.
1) call LayerTreeHost::InitializeRendererIfNeeded when a method on webkit thread
needs the output surface, ie CompositeAndReadback. Blocks until everything
recreated. But that only works in ThreadProxy if:
2) Check output surface lost already detected in
ThreadProxy::CheckOutputSurfaceStatusOnImplThread, which kicks off a chain of
recreate attempts.

So I'm guessing 1) is used in single thread mode and 2) threaded mode? 1) blocks
in ThreadProxy which I thought was weird because it ignores the recreate
attempts started by the scheduler (or am I reading the code wrong?).

I think the paths can be more unified if in threaded mode, 1) only checks but
not block.

> 
> In this new initialization path the capabilities are not set after the initial
> blocking init happens.  Is that OK?  Is anything likely to query the
> capabilities early and if so is there any mechanism to prevent that?

Yes it is a problem, at least in tests. I'm thinking of blocking at the places
where the capabilities are needed, but the code in my head feels horrible.

Replace "DCHECK(has_renderer_capabilities)" with
if (!has_renderer_capabilities)
  renderer_initialized_.Wait()

Then when renderer is first initialized on impl thread:
renderer_initialized_.Signal()
MainThread->PostTask(RendererInitalized) // Will cancell/noop if already
initialized

Feels super hacky, but I can't think of anything else. WDYT?

And finally LayerTreeHostClient::DidInitializeRenderer is going away. Tests
should work as is without it.

[jamesr, 2013-04-03 00:17:01]

On 2013/04/02 23:57:15, boliu wrote:
> On 2013/04/02 22:42:08, jamesr wrote:
> > Is there something specific you want me to look at?
> 
> Just the general direction this patch is going. So mainly scheduler,
> scheduler_state_machine, and how it interacts with thread_proxy.
> 
> > This looks incomplete, but
> > I think that's expected.  Here are a few questions:
> 
> Wow, great questions. I'm running into them as I was working through
> crashing/failing tests. (Great tests btw)
> 
> > 
> > It doesn't look like the case where the initialization fails on the first
try
> is
> > handled here, is it?
> 
> It would call into LayerTreeHost::OnRendererInitialized(false). It's still
> incomplete. So far it's called if Renderer::Initialize fails, but not for
> OutputSurface::BindToClient. Also it should trigger output lost path in
> scheduler.

It should be OK to treat a deferred context initialization failure in the same
way as a lost context, but they aren't idential today.  I suspect you'll hit
this in a number of tests, etc, but I'm not aware of any concrete thing that
will definitely break if we change this.  Just be aware that it's different.

> 
> > 
> > I don't think we want to have separate paths for creation and recreation,
but
> I
> > suspect you're still working on unifying those, right?
> 
> Currently they are the same in schduler/state_machine, but diverges in between
> LTH and Proxy, since recreate is sync.
> 
> Looking at the code again, I'm now slightly confused about what triggers a
> recreate.
> 1) call LayerTreeHost::InitializeRendererIfNeeded when a method on webkit
thread
> needs the output surface, ie CompositeAndReadback. Blocks until everything
> recreated. But that only works in ThreadProxy if:
> 2) Check output surface lost already detected in
> ThreadProxy::CheckOutputSurfaceStatusOnImplThread, which kicks off a chain of
> recreate attempts.
> 
> So I'm guessing 1) is used in single thread mode and 2) threaded mode? 1)
blocks
> in ThreadProxy which I thought was weird because it ignores the recreate
> attempts started by the scheduler (or am I reading the code wrong?).
> 
> I think the paths can be more unified if in threaded mode, 1) only checks but
> not block.

You're correct that the single-thread and threaded paths are not entirely the
same.  We normally just let the compositor thread detect a lost context and
trigger the ThreadProxy recreation logic, but in the case where we need a
synchronous response (i.e. CompositeAndReadback) the webkit thread blocks until
the context is created.  It's not ignoring the scheduler so much as blocking
until the scheduler makes it past a certain point.  I don't think
CompositeAndReadback() can ever be called for webview, so I think we'll just
have to live with the fact that it needs to run even if we don't have a vsync
tick.  It's a special case.

Ignoring for a moment the CompositeAndReadback case, I think your understanding
is correct.  The ThreadProxy checks for lost contexts and, if necessary,
triggers the recreation logic.

> 
> > 
> > In this new initialization path the capabilities are not set after the
initial
> > blocking init happens.  Is that OK?  Is anything likely to query the
> > capabilities early and if so is there any mechanism to prevent that?
> 
> Yes it is a problem, at least in tests. I'm thinking of blocking at the places
> where the capabilities are needed, but the code in my head feels horrible.

I *think* it's the case that only tests depend on renderer_capabilities being up
to date before we call ThreadProxy::BeginFrame, and if so we should simply
rework the tests.  We shouldn't add blocking logic in production code unless we
have a concrete and understood need for it.  However, I'm not sure of what
production code might need access to the capabilities.  Have you found any?   If
you do, we'll have to look at them case-by-case to figure out what the
requirement is.

> 
> Replace "DCHECK(has_renderer_capabilities)" with
> if (!has_renderer_capabilities)
>   renderer_initialized_.Wait()
> 
> Then when renderer is first initialized on impl thread:
> renderer_initialized_.Signal()
> MainThread->PostTask(RendererInitalized) // Will cancell/noop if already
> initialized
> 
> Feels super hacky, but I can't think of anything else. WDYT?
> 
> And finally LayerTreeHostClient::DidInitializeRenderer is going away. Tests
> should work as is without it.

[boliu, 2013-04-03 19:20:49]

Question about retrying recreate logic. What is it trying to accomplish? The
retry logic only applies in recreate case; if the first initialization fails,
then we fallback to software immediately. And then there's this scary looking
comment:

// Tolerate a certain number of recreation failures to work around races
// in the output-surface-lost machinery.

In threaded mode, if recreate depends on vsync, then 5 failures would take 5 x
16 = 80ms. That's a lot of lost frames...

[boliu, 2013-04-04 00:16:36]

Hey James, could you take a look at layer_tree_host, single_thread_proxy, and
thread_proxy.

I tried to merge the initial create and recreate paths. The initial create and
recreate logic diverge conditioned on has_renderer_capabilities_ variables.

Still need to bring back synchronous recreate for
ThreadProxy::CompositeAndReadback.

ThreadProxy::BeginFrame should not need to synchronous recreate since it's
triggered by the scheduler, right?

Also the question below:

On 2013/04/03 19:20:49, boliu wrote:
> Question about retrying recreate logic. What is it trying to accomplish? The
> retry logic only applies in recreate case; if the first initialization fails,
> then we fallback to software immediately. And then there's this scary looking
> comment:
> 
> // Tolerate a certain number of recreation failures to work around races
> // in the output-surface-lost machinery.
> 
> In threaded mode, if recreate depends on vsync, then 5 failures would take 5 x
> 16 = 80ms. That's a lot of lost frames...

[boliu_use_chromium_pls, 2013-04-09 02:10:59]

Status update: Implementation probably correct since last few failing tests were
due to some assumptions no longer hold. Only one failing test left. Code is a
bit of a mess still.

This is growing to be a massive and complex patch...

[jamesr, 2013-04-09 21:26:19]

I'm not sure I understand why the logic for initially creating the renderer is
different from the logic when recreating.  Could you explain what's different?

https://codereview.chromium.org/12544032/diff/32001/cc/scheduler/scheduler_st...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/32001/cc/scheduler/scheduler_st...
cc/scheduler/scheduler_state_machine.cc:185: return ACTION_INITIALIZE_RENDERER;
why is INITIALIZE a distinct state from RECREATION?

[boliu, 2013-04-09 21:53:07]

On 2013/04/09 21:26:19, jamesr wrote:
> I'm not sure I understand why the logic for initially creating the renderer is
> different from the logic when recreating.  Could you explain what's different?
> 

The difference should all inside thread_proxy/LTH, examples:
renderer capabilities are set on first init only
offscreen context is only checked/recreated on recreate

For, LTHI, Scheduler, and SchedulerStateMachine, they *should* be exactly the
same. This is not the case yet since there's Scheduler::DidCreateOutputSurface
and DidRecreateOutputSurface, but these two calls should be merged.

And a couple more things:
Unfortunately, there is one more recreate path, the synchronous version for
CompositeAndReadback. I have not tried to see if this version works yet since
there are no existing tests explicitly testing CompositeAndReadback. So need to
add some tests there.

Also please give me a chance to clean things up before you look at things too
closely. I think that mostly involves using better function names and adding
comments to make things easier to understand. I expect there will still be 3
distinct paths though, even with common code sharing.

https://codereview.chromium.org/12544032/diff/32001/cc/scheduler/scheduler_st...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/32001/cc/scheduler/scheduler_st...
cc/scheduler/scheduler_state_machine.cc:185: return ACTION_INITIALIZE_RENDERER;
On 2013/04/09 21:26:19, jamesr wrote:
> why is INITIALIZE a distinct state from RECREATION?

OUTPUT_SURFACE_RECREATING leads to ACTION_BEGIN_OUTPUT_SURFACE_RECREATION which
kicks off the whole recreate sequence in thread_proxy that involves 3 steps:

1) CreateOutputSurface on main thread
2) LTHI::SetOutputSurface on impl thread
3) LTHI::InitializeRenderer on impl thread

Step 2 success will transition the state from RECREATING to PENDING_RENDERER,
which will call back with ACTION_INITIALIZE_RENDERER (ie Step 3) inside vsync
here.

For reference, 2) and 3) were a single step (LTHI::InitializeRenderer) before
this patch.

[jamesr, 2013-04-09 21:54:59]

On 2013/04/09 21:53:07, boliu wrote:
> On 2013/04/09 21:26:19, jamesr wrote:
> > I'm not sure I understand why the logic for initially creating the renderer
is
> > different from the logic when recreating.  Could you explain what's
different?
> > 
> 
> The difference should all inside thread_proxy/LTH, examples:
> renderer capabilities are set on first init only
> offscreen context is only checked/recreated on recreate

Hmm - if that's true, then it's a bug.  If the capabilities are different after
a context loss + recreation then we need to reflect that everywhere.  The
capabilities are tied to the OutputSurface.

> 
> For, LTHI, Scheduler, and SchedulerStateMachine, they *should* be exactly the
> same. This is not the case yet since there's Scheduler::DidCreateOutputSurface
> and DidRecreateOutputSurface, but these two calls should be merged.

OK.  Do you plan to merge those in this patch or elsewhere?

> 
> And a couple more things:
> Unfortunately, there is one more recreate path, the synchronous version for
> CompositeAndReadback. I have not tried to see if this version works yet since
> there are no existing tests explicitly testing CompositeAndReadback. So need
to
> add some tests there.

Yes, that one's weird.

> 
> Also please give me a chance to clean things up before you look at things too
> closely. I think that mostly involves using better function names and adding
> comments to make things easier to understand. I expect there will still be 3
> distinct paths though, even with common code sharing.
> 

OK.  Why do you think there will be 3 distinct paths?  What parts of them are
different?


>
https://codereview.chromium.org/12544032/diff/32001/cc/scheduler/scheduler_st...
> File cc/scheduler/scheduler_state_machine.cc (right):
> 
>
https://codereview.chromium.org/12544032/diff/32001/cc/scheduler/scheduler_st...
> cc/scheduler/scheduler_state_machine.cc:185: return
ACTION_INITIALIZE_RENDERER;
> On 2013/04/09 21:26:19, jamesr wrote:
> > why is INITIALIZE a distinct state from RECREATION?
> 
> OUTPUT_SURFACE_RECREATING leads to ACTION_BEGIN_OUTPUT_SURFACE_RECREATION
which
> kicks off the whole recreate sequence in thread_proxy that involves 3 steps:
> 
> 1) CreateOutputSurface on main thread
> 2) LTHI::SetOutputSurface on impl thread
> 3) LTHI::InitializeRenderer on impl thread
> 
> Step 2 success will transition the state from RECREATING to PENDING_RENDERER,
> which will call back with ACTION_INITIALIZE_RENDERER (ie Step 3) inside vsync
> here.
> 
> For reference, 2) and 3) were a single step (LTHI::InitializeRenderer) before
> this patch.

[boliu, 2013-04-09 22:08:48]

On 2013/04/09 21:54:59, jamesr wrote:
> On 2013/04/09 21:53:07, boliu wrote:
> > The difference should all inside thread_proxy/LTH, examples:
> > renderer capabilities are set on first init only
> > offscreen context is only checked/recreated on recreate
> 
> Hmm - if that's true, then it's a bug.  If the capabilities are different
after
> a context loss + recreation then we need to reflect that everywhere.  The
> capabilities are tied to the OutputSurface.
> 

I might be overstating it: tt's updated in thread_proxy, but there are bits not
updated in LHI. If you look at existing code, some LTH settings are only set in
LTH::InitializeRenderer, which is only called if renderer_initialized_ is false,
which once set to true, is never set to false again. Is this a problem?

> > 
> > For, LTHI, Scheduler, and SchedulerStateMachine, they *should* be exactly
the
> > same. This is not the case yet since there's
Scheduler::DidCreateOutputSurface
> > and DidRecreateOutputSurface, but these two calls should be merged.
> 
> OK.  Do you plan to merge those in this patch or elsewhere?

This patch, I added DidCreateOutputSurface and now realize there's no
difference.

> > 
> > Also please give me a chance to clean things up before you look at things
too
> > closely. I think that mostly involves using better function names and adding
> > comments to make things easier to understand. I expect there will still be 3
> > distinct paths though, even with common code sharing.
> > 
> 
> OK.  Why do you think there will be 3 distinct paths?  What parts of them are
> different?
> 

I'd have to actually try to merge them again and see what the differences in
logic are. The two in my head I've stated above.

But a big part is because some paths are synchronous are not, so some might
expect direct return value and some might expect a callback instead etc. So
again these 3 steps:
1) CreateOutputSurface on main thread
2) LTHI::SetOutputSurface on impl thread
3) LTHI::InitializeRenderer on impl thread

In first init, 1) is sync, 2 and 3 are async.
In regular recreate (after this patch), all three steps are async. Also this
path has retry on failure logic.
In sync recreate, all 3 are sync.

[jamesr, 2013-04-09 22:29:50]

On 2013/04/09 22:08:48, boliu wrote:
> On 2013/04/09 21:54:59, jamesr wrote:
> > On 2013/04/09 21:53:07, boliu wrote:
> > > The difference should all inside thread_proxy/LTH, examples:
> > > renderer capabilities are set on first init only
> > > offscreen context is only checked/recreated on recreate
> > 
> > Hmm - if that's true, then it's a bug.  If the capabilities are different
> after
> > a context loss + recreation then we need to reflect that everywhere.  The
> > capabilities are tied to the OutputSurface.
> > 
> 
> I might be overstating it: tt's updated in thread_proxy, but there are bits
not
> updated in LHI. If you look at existing code, some LTH settings are only set
in
> LTH::InitializeRenderer, which is only called if renderer_initialized_ is
false,
> which once set to true, is never set to false again. Is this a problem?

Yes - I think those are incorrect.  Any settings we get from the OutputSurface
have to be updated whenever we get a new OutputSurface.

> > > 
> > > Also please give me a chance to clean things up before you look at things
> too
> > > closely. I think that mostly involves using better function names and
adding
> > > comments to make things easier to understand. I expect there will still be
3
> > > distinct paths though, even with common code sharing.
> > > 
> > 
> > OK.  Why do you think there will be 3 distinct paths?  What parts of them
are
> > different?
> > 
> 
> I'd have to actually try to merge them again and see what the differences in
> logic are. The two in my head I've stated above.
> 
> But a big part is because some paths are synchronous are not, so some might
> expect direct return value and some might expect a callback instead etc. So
> again these 3 steps:
> 1) CreateOutputSurface on main thread
> 2) LTHI::SetOutputSurface on impl thread
> 3) LTHI::InitializeRenderer on impl thread
> 
> In first init, 1) is sync, 2 and 3 are async.
> In regular recreate (after this patch), all three steps are async. Also this
> path has retry on failure logic.
> In sync recreate, all 3 are sync.

I don't think there is necessarily any reason why first init has to be sync.  If
it wasn't, would there still be different paths for anything other than
CompositeAndReadback() ?

[boliu, 2013-04-09 22:47:18]

On 2013/04/09 22:29:50, jamesr wrote:
> Yes - I think those are incorrect.  Any settings we get from the OutputSurface
> have to be updated whenever we get a new OutputSurface.
> 

So I really don't want to bloat this patch anymore and really want to land this
asap to unblock other people. Can I fix it after this lands? (Or possibly before
if this gets reverted for perf or other reasons...)

> I don't think there is necessarily any reason why first init has to be sync. 
If
> it wasn't, would there still be different paths for anything other than
> CompositeAndReadback() ?

The one difference is first init fails immediately, regular recreate has retry
logic, but that's logic in LTH only, not thread_proxy. Can't think of anything
else right now, so should be possible to merged them.

I'll try merging, although not looking forward to fixing tests that assume
OutputSurface is created on init :/

[jamesr, 2013-04-09 22:54:31]

On 2013/04/09 22:47:18, boliu wrote:
> On 2013/04/09 22:29:50, jamesr wrote:
> > Yes - I think those are incorrect.  Any settings we get from the
OutputSurface
> > have to be updated whenever we get a new OutputSurface.
> > 
> 
> So I really don't want to bloat this patch anymore and really want to land
this
> asap to unblock other people. Can I fix it after this lands? (Or possibly
before
> if this gets reverted for perf or other reasons...)

I think it's more important to make sure that this patch works correctly.  As
you're probably well aware now this is a difficult area and we need to make sure
we're proceeding carefully.

> 
> > I don't think there is necessarily any reason why first init has to be sync.

> If
> > it wasn't, would there still be different paths for anything other than
> > CompositeAndReadback() ?
> 
> The one difference is first init fails immediately, regular recreate has retry
> logic, but that's logic in LTH only, not thread_proxy. Can't think of anything
> else right now, so should be possible to merged them.
> 
> I'll try merging, although not looking forward to fixing tests that assume
> OutputSurface is created on init :/

[danakj, 2013-04-10 16:40:14]

Is there any way to stage this change into a few smaller patches? If it's
possible, that would help a lot in grokking and ensuring things are done
correctly.

https://codereview.chromium.org/12544032/diff/43001/cc/scheduler/scheduler.cc
File cc/scheduler/scheduler.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/scheduler/scheduler.cc...
cc/scheduler/scheduler.cc:117: }
Why doesn't this ProcessScheduledActions?

https://codereview.chromium.org/12544032/diff/43001/cc/scheduler/scheduler_st...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/scheduler/scheduler_st...
cc/scheduler/scheduler_state_machine.cc:426: output_surface_state_ ==
OUTPUT_SURFACE_PENDING_RENDERER)
If the renderer isn't recreated, but the output surface is lost, I think it's
wrong to drop the lost event here. We should reset to output surface lost and go
from there. Initializing a renderer with a lost output surface isn't helpful,
which I think this is going to try to do?

Maybe the renderer init will fail in this case and we'll get back to the lost
state, but it's a bit more indirect, and makes HasOutputSurface() lie, is there
any reason for that?

(Sounds like a test would be good for this case if there isn't one)

https://codereview.chromium.org/12544032/diff/43001/cc/scheduler/scheduler_un...
File cc/scheduler/scheduler_unittest.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/scheduler/scheduler_un...
cc/scheduler/scheduler_unittest.cc:586: scheduler->DidInitializeRenderer(true);
Seems like you don't need this init renderer?

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.cc
File cc/test/fake_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.cc#new...
cc/test/fake_proxy.cc:20: DCHECK(host_);
nit: no need to dcheck a pointer youre about to deref on the next line.

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.h
File cc/test/fake_proxy.h (right):

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.h#newc...
cc/test/fake_proxy.h:20: void SetHost(LayerTreeHost* host);
nit: set_layer_tree_host(). this can be an inline method in the header, it's a
simple setter.

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.h#newc...
cc/test/fake_proxy.h:50: LayerTreeHost* host_;
nit: layer_tree_host_

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.cc
File cc/test/layer_tree_test.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.c...
cc/test/layer_tree_test.cc:93: test_hooks_->DidSetOutputSurface(this);
instead of only calling this on true, can you call this always, but pass the
result to the method. See PrepareToDrawOnThread() and SwapBuffersOnThread() as
examples of this.

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.c...
cc/test/layer_tree_test.cc:441: FakeOutputSurface* fake_output_surface =
This isn't great, there's no guarantee that a test doesn't override
CreateOutputSurface and create something that isn't a FakeOutputSurface.

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.c...
cc/test/layer_tree_test.cc:449: base::Unretained(this),
unretained pointers seems like it's going to potentially cause flake. what if
the test shuts down before this task is handled?

why do you post-task for this anyways? you're already on the impl thread here.

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.c...
cc/test/layer_tree_test.cc:456: fake_output_surface->DidVSync(frame_time_);
who sets frame_time_?

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.h
File cc/test/layer_tree_test.h (right):

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.h...
cc/test/layer_tree_test.h:36: virtual void
DidSetOutputSurface(LayerTreeHostImpl* host_impl) {}
nit: DidSetOutputSurfaceOnThread

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:163: if (has_renderer_capabilities_) {
I'm having trouble groking this function.

1. If you have a renderer already, then you check if the output surface was
created and retry if not?

2. If you don't have a renderer, and you didn't create an output surface, then
it gives up?

Why is any of the recreate-output-surface part of this function dependent on if
you have initialized the renderer? As soon as the output surface is lost, the
renderer should be considered lost too, including its capabilities.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:170: client_->WillRetryRecreateOutputSurface();
This should happen before we recreate, not after. In the case DidRecreate
succeeds above, this wouldn't even happen?

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:188: } else {
nit: no else needed, the if() block returned.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:234: if (has_renderer_capabilities_)
i'm not sure i see the benefit of renaming this variable. has its meaning
changed? initialized should be == having capabilities.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:519: bool LayerTreeHost::IsOutputSurfaceLost() const
{
This is kind of a lie. If output surface is not lost but the renderer isn't
ready, then this returns true.

I'd rather name this something more precise like IsRendererInitialized() (well,
that'd be the opposite, but you get the idea).

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:521: return output_surface_lost_ ||
!has_renderer_capabilities_;
Is it possible that output_surface_lost_ = true, but has_renderer_caps_ = true?
That would seem like a bug.

I would think this function would be more like the following to enforce that, if
it's true:

DCHECK(!output_surface_lost_ || !has_renderer_capabilities_);
return has_renderer_capabilities_;

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:721: if (output_surface_lost_ ||
!has_renderer_capabilities_) {
Reuse the IsOutputSurfaceLost() function here?

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:722: RecreateOutputSurface();
Why does not having a renderer cause us to recreate the output surface?

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:724: return !output_surface_lost_ &&
has_renderer_capabilities_;
can reuse IsOutputSurfaceLost here as well.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1296: bool
LayerTreeHostImpl::InitializeRendererForTest(
This calls other public functions. Are you planning to remove this function and
just make these calls directly in the tests?

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.h (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.h:206: bool InitializeRendererForTest(
nit: *ForTesting(

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_unittest.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_unittest.cc:1570: class LayerTreeHostWithProxy : public
LayerTreeHost { public:
typo here

[boliu, 2013-04-10 17:36:35]

On 2013/04/10 16:40:14, danakj wrote:
> Is there any way to stage this change into a few smaller patches? If it's
> possible, that would help a lot in grokking and ensuring things are done
> correctly.

Thanks for reviewing. Unfortuantely this patch really isn't ready for close
review yet. I know it's close to impossible to understand right now (I can't
keep all the details in my head). Should get better after the different paths
are merged and after I come up with better names for things.

I'm not sure yet about splitting into smaller patches. A few things came up that
are really independent changes to the original code, but I don't know how easy
it is to untangle those changes.

Left some inline replies.

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.cc
File cc/test/fake_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/test/fake_proxy.cc#new...
cc/test/fake_proxy.cc:20: DCHECK(host_);
On 2013/04/10 16:40:14, danakj wrote:
> nit: no need to dcheck a pointer youre about to deref on the next line.

Benefit is this makes the crash explicit. Without DCHECK, the crash would be
somewhere inside OnCreateAttemped

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.cc
File cc/test/layer_tree_test.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/test/layer_tree_test.c...
cc/test/layer_tree_test.cc:456: fake_output_surface->DidVSync(frame_time_);
On 2013/04/10 16:40:14, danakj wrote:
> who sets frame_time_?

No one! This was a the case with the vsync test and I just moved the code here.
Haven't bothered to check what it's used for yet...

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:170: client_->WillRetryRecreateOutputSurface();
On 2013/04/10 16:40:14, danakj wrote:
> This should happen before we recreate, not after. In the case DidRecreate
> succeeds above, this wouldn't even happen?

This is the exact same behavior as LayerTreeHost::RecreateOutputSurface before
this patch. And I don't think it's wrong, it's *retrying* a recreate after it
fails, so if recreate suceeds the first time, it should not be called.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:234: if (has_renderer_capabilities_)
On 2013/04/10 16:40:14, danakj wrote:
> i'm not sure i see the benefit of renaming this variable. has its meaning
> changed? initialized should be == having capabilities.

Agree it's a bad name.

The has_renderer_cap vars are used to distinguish the first creating output
surface/initializing renderer, vs something lost and recreating. But as the
latest discussion with James, there are code where there should be no
distinction like update settings_ above. This also makes has_cap a bad name
since capabilities should be updated on recreate.

Just rename to something like is_first_init.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:521: return output_surface_lost_ ||
!has_renderer_capabilities_;
On 2013/04/10 16:40:14, danakj wrote:
> Is it possible that output_surface_lost_ = true, but has_renderer_caps_ =
true?
> That would seem like a bug.

Yes. See above comment, has_renderer_caps should really be renamed to something
like has_first_initialized_renderer. Basically once
has_first_initialized_renderer is set to true, it's never set to false again.

Note I think that this var might no longer be needed here, but will still be
needed in thread_proxy.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1296: bool
LayerTreeHostImpl::InitializeRendererForTest(
On 2013/04/10 16:40:14, danakj wrote:
> This calls other public functions. Are you planning to remove this function
and
> just make these calls directly in the tests?

A lot of tests calls this. I don't think it's better replace each callsite with
the body of this function due to the DRY principle. But would be better to move
this somewhere compiled for tests only, but still available to all tests, any
suggestions?

[danakj, 2013-04-10 17:51:00]

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host....
cc/trees/layer_tree_host.cc:170: client_->WillRetryRecreateOutputSurface();
On 2013/04/10 17:36:36, boliu wrote:
> On 2013/04/10 16:40:14, danakj wrote:
> > This should happen before we recreate, not after. In the case DidRecreate
> > succeeds above, this wouldn't even happen?
> 
> This is the exact same behavior as LayerTreeHost::RecreateOutputSurface before
> this patch. And I don't think it's wrong, it's *retrying* a recreate after it
> fails, so if recreate suceeds the first time, it should not be called.

Ah, okay, quite right. I guess it's just my general confusion about how this
function is used at the moment.

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/12544032/diff/43001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1296: bool
LayerTreeHostImpl::InitializeRendererForTest(
On 2013/04/10 17:36:36, boliu wrote:
> On 2013/04/10 16:40:14, danakj wrote:
> > This calls other public functions. Are you planning to remove this function
> and
> > just make these calls directly in the tests?
> 
> A lot of tests calls this. I don't think it's better replace each callsite
with
> the body of this function due to the DRY principle. But would be better to
move
> this somewhere compiled for tests only, but still available to all tests, any
> suggestions?

I think most of the calls are in the LayerTreeHostImpl tests? I'd suggest
putting a CreateLayerTreeHostImpl(scoped_ptr<OutputSurface>) function in the
LTHI test base class. Then have tests call that instead of calling
LTHI::Create();LTHI::InitializeRendererForTesting();

Most other tests could just make the real calls, I think. If there's a bunch of
duplication in another test file, you could follow a similar pattern. Seem
reasonable?

[boliu, 2013-04-11 19:29:26]

Cleaned up thread_proxy, merging/simplifying functions etc. Have not renamed
anything though. But it's finally somewhat sane to read and follow now.

Have not changed anything else or address any comments from previous review yet,
so don't look at other files yet.

[danakj, 2013-04-12 00:38:35]

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:994: if (was_first_create &&
has_renderer_capabilities_on_impl_thread_)
accessing an impl variable on the main thread without a lock = no.

but you just passed this value in with the bind, so you shouldn't need it right?
in fact, this condition would never be true since was_first_create =
!has_renderer_caps_on_impl_thread

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:995: return;
why would this function even be called then in this scenario? should this be a
dcheck/notreached?

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1000:
Proxy::MainThread()->PostTask(output_surface_recreation_callback_.callback());
I'm not clear why this is a PostTask to the main thread when we're already on
the main thread. James, what's the logic here in the old code?

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1004: bool initialize_renderer_ignoring_vsync) {
I think an enum here instead of a bool woudl help readability a bunch

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1015: if (!success) goto done;
Heh, please do this without gotos. :)

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1094: void
ThreadProxy::InitializeOutputSurfaceOnImplThread(
this should be ::RecreateOutputSurface... I guess

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1108: return;
Should this tell the caller that it didn't do anything? This is going to return
success = true, implicitly, but it's not obvious IMO. This could be more clear.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1122: } else if (offscreen_context_provider) {
seems like this should be an early out

if !success
  bind/verify contexts
  signal
  return

then youll have much less if (success) checks here.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1127: if (*success &&
initialize_renderer_ignoring_vsync) {
rahter than "ignoring_vsync" in here, what about something like
"initialize_renderer_immediately"? or "synchronously".. or something.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1128: *success = DoInitializeRendererOnImplThread();
How does the offscreen context provider get to the init renderer function in
this case?

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1129: if (*success && capabilities) {
are the caps NULL sometimes? I dont see that.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1167:
offscreen_context_provider_passed_->VerifyContexts();
same comment about an early-out condition. you could do this right after trying
to initialize and return there.

[danakj, 2013-04-12 00:39:31]

There's a lot of naming stuff to clean up and the code feels a bit haphazard
with so many nested ifs. I think some time spent making that more clear would be
well invested.

Overall I think I see where the class is going and it seems reasonable.

[boliu, 2013-04-12 02:10:20]

Addressed some comments but still horrible names everywhere.

Ran through the default set of trybots on PS13. Seems to have a bunch of
failures on aura/chromeos bots which is a little worrying since most are show gl
related errors. Not sure if this is normal level of flakiness or if this patch
made things worse..

Layout test failures do not seem to be real, even if they are related to
compositing. I can't reproduce them locally.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:994: if (was_first_create &&
has_renderer_capabilities_on_impl_thread_)
On 2013/04/12 00:38:35, danakj wrote:
> accessing an impl variable on the main thread without a lock = no.
> 
> but you just passed this value in with the bind, so you shouldn't need it
right?
> in fact, this condition would never be true since was_first_create =
> !has_renderer_caps_on_impl_thread

changed to main thread copy

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:995: return;
On 2013/04/12 00:38:35, danakj wrote:
> why would this function even be called then in this scenario? should this be a
> dcheck/notreached?

This is the two paths, synchronous RecreateOutputSurfaceAndInitializeRenderer
and the async one here, interacting in bad ways.

So the async path is kicked off when first initialized, then if
RecreateOutputSurfaceAndInitializeRenderer is called immediately after and wins
the race, can actually fall into this case.

LayerTreeHostTestDeviceScaleFactorScalesViewportAndLayers.RunMultiThread is the
first test that does this, and without this early return, it just hangs.

I would like to understand why the test hangs without this, but I presume it's
probably a test problem.

I would also like add more tests specifically testing how these two recreate
paths interact

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1000:
Proxy::MainThread()->PostTask(output_surface_recreation_callback_.callback());
On 2013/04/12 00:38:35, danakj wrote:
> I'm not clear why this is a PostTask to the main thread when we're already on
> the main thread. James, what's the logic here in the old code?

This is for the *retrying* recreate if it fails.
output_surface_recreation_callback_ is posted again if LTH::OnCreateAttemped
returns retry, and cancelled if succeeds.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1094: void
ThreadProxy::InitializeOutputSurfaceOnImplThread(
On 2013/04/12 00:38:35, danakj wrote:
> this should be ::RecreateOutputSurface... I guess

used for both initial create and recreate, so hard to come up with sensible
names...

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1108: return;
On 2013/04/12 00:38:35, danakj wrote:
> Should this tell the caller that it didn't do anything? This is going to
return
> success = true, implicitly, but it's not obvious IMO. This could be more
clear.

Going to make default to false at callsite and explicitly set to true here.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1122: } else if (offscreen_context_provider) {
On 2013/04/12 00:38:35, danakj wrote:
> seems like this should be an early out
> 
> if !success
>   bind/verify contexts
>   signal
>   return
> 
> then youll have much less if (success) checks here.

Done.

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1128: *success = DoInitializeRendererOnImplThread();
On 2013/04/12 00:38:35, danakj wrote:
> How does the offscreen context provider get to the init renderer function in
> this case?

Bug! Make setting offscreen_context_provider_passed_ unconditioned

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1129: if (*success && capabilities) {
On 2013/04/12 00:38:35, danakj wrote:
> are the caps NULL sometimes? I dont see that.

in older version..

Removed this check and add DCHECK at beginning of function for success and
capabilities

https://codereview.chromium.org/12544032/diff/64001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:1167:
offscreen_context_provider_passed_->VerifyContexts();
On 2013/04/12 00:38:35, danakj wrote:
> same comment about an early-out condition. you could do this right after
trying
> to initialize and return there.

Removed the !has_renderer_capabilities_on_impl_thread_ above as James was saying
we should be updating these capabilities on every recreate.

Then merge the into a single if/else if

[boliu, 2013-04-22 16:00:13]

Ready for a closer look for merging code paths.

[danakj, 2013-04-22 18:03:41]

Hey, this is pretty cool! I left a whole bunch of comments for you. I think we
can get rid of a couple variables/functions to help simplify the state we need
in our heads.

The terminology is becoming awkward. Previously we had "Create output surface"
and "Initialize renderer". Now we have "CreateAndInitializeOutputSurface" but it
doesn't *really* mean anything to init the output surface. It's a renderer we're
initializing. I nitted a few places with names to make it consistent with the
overall patch, but I'm not totally sold on the "InitializeOutputSurface" part of
the namings. I'm not sure what to suggest right now tho other than
CreateOutputSurfaceAndInitializeRenderer which is long.. but more correct. And
then you'd have things like Scheduler::HasInitializedRenderer() instead of
HasOutputSurface(). WDYT?

Can you add some tests for the new code paths? Specifically:
1. If the context is lost twice during the first initialization, that the
compositor still comes up and can produce frames after (but not before).
2. If the context is lost many times during the first initialization, the
compositor fails and reports DidCreateOutputSurface(false) to its client.

I think that would more or less get them.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:184: if (output_surface_state_ ==
OUTPUT_SURFACE_LOST && can_begin_frame_)
We should follow up with a rename for this variable, and the whole
SetSurfaceReady() thing, I think. This is "embedder ready" or "lth client ready"
really.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:197: ((visible_ && can_begin_frame_) ||
needs_forced_commit_))
Do you need can_begin_frame_ here? How about checking OUTPUT_SURFACE_ACTIVE
instead? Since now, O_S_LOST doesn't imply that we report BEGIN_O_S_CREATION
anymore.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:429: if (had_output_surface_)
This variable gets set true here, then stays true forever. So, we're
SetNeedsCommit() when we create the first output surface, but not when we
recreate after a loss? Why is that? We used to SetNeedsCommit() after a loss.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.h:142: void DidCreateOutputSurface();
nit: DidCreateAndInitializeOutputSurface?

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.h:143: bool HasOutputSurface() const;
nit: HasInitializedOutputSurface?

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine_unittest.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:387:
state.DidCreateOutputSurface();
Should you just do this CanBeginFrame/CreateOutputSurface dance once at the
start of the test? The surface isn't being lost in this test.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:413:
state.SetCanBeginFrame(true);
Do you need to do it again here?

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:458:
state.SetCanBeginFrame(true);
Same question here and on the next test below.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:724:
state.UpdateState(state.NextAction());
Can you add a unit test that verifies NextAction() is what we expect it to be
before calling UpdateState() like this? And that NextAction() changes
appropriately then after DidCreateOS()?

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:729:
state.DidLoseOutputSurface();
Can you verify what NextAction() is before calling DidLoseOS()? So we can see it
changes to BEGIN_O_S_CREATION afterward.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:756:
state.DidLoseOutputSurface();
Same here please verify NextAction()

https://codereview.chromium.org/12544032/diff/105001/cc/test/fake_proxy.h
File cc/test/fake_proxy.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/test/fake_proxy.h#new...
cc/test/fake_proxy.h:20: void SetHost(LayerTreeHost* host);
nit: SetLayerTreeHost

https://codereview.chromium.org/12544032/diff/105001/cc/test/fake_proxy.h#new...
cc/test/fake_proxy.h:50: LayerTreeHost* host_;
nit: layer_tree_host_

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:86: had_output_surface_(false),
I'd like this variable to go away, and I think it's possible. I've commented at
each site what I think could replace it.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:87: output_surface_lost_(false),
Should this start true now? Then HasOutputSurface() can just check this
variable.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:126: return true;
If this is always true, then the method should not return a bool, and
LTH::Create() should never return NULL.

That might be a rather large change of it's own, touching embedders etc, so
probably makes sense as a followup patch.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:158: client_->DidRecreateOutputSurface(true);
It would make unit testing better if this was called always, but I realize that
might mess with the current embedder implementations. Did you try it?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:175: if (!had_output_surface_) {
How about if (!contents_texture_manager) {} ?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:194: } else {
No need for else when the if block returned.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:196: client_->WillRetryRecreateOutputSurface();
Rename this WillRetryCreateOutputSurface() and call this always here. It will
help you unit test failure recovery during the first initialization.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:202: if (!had_output_surface_ ||
num_failed_recreate_attempts_ > 5) {
What is the advantage of unifying this code if we don't allow it to retry the
same way? I don't think we want the !had_output_surface_ here.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:221: if (had_output_surface_)
how about just if (contents_texture_manager_)

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:503: if (had_output_surface_) {
if (!output_surface_lost_) ?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:525: if (!had_output_surface_)
I think this if can just go away. The LTHI will early out as appropriate.

(And it would be nice to minimize our dependence on had_output_surface_ so we
can see what is really depending on it)

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.h:125: CreateResult OnCreateAttempted(bool success);
OnCreateAndInitializeOutputSurfaceAttempted()

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:984:
context3d_->set_have_extension_io_surface(true);
nit: how about output_surface->Context3d()->set_have...

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:103: void
SingleThreadProxy::CreateAndInitializeOutputSurface() {
Why doesn't this call DidStartOutputSurfaceCreation() like the thread proxy?
Should we test that?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:130:
layer_tree_host_->DeleteContentsTexturesOnImplThread(
I don't think this needs to be inside the if(had_renderer_caps) block. LTH does
the right thing. And this implicitly ties the proxy "had_renderer_capabilities"
to state in the LTH which I dislike. Can we just call this always when we get
this far? Maybe do this just before InitializeRenderer()?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:147: if (had_renderer_capabilities) {
I think this if() isn't serving much purpose, can we remove it and just call
set_offscreen_c_p() always here? We'll always have one thanks to the early-out
above if we're supposed to have one. And setting it to NULL when we don't is
fine.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:151: } else if (had_renderer_capabilities &&
offscreen_context_provider) {
else if(offscreen_context_provider) is enough.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:182: void ThreadProxy::DoCreateAndInitializeContext() {
s/Context/OutputSurface/

This "Context" reference is a hold-over from before we had output surfaces.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:191: scoped_refptr<ContextProvider>
offscreen_context_provider;
Move this below the early out if it's not used

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:230: void ThreadProxy::OnContextInitializeAttempted(
s/Context/OutputSurface/

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:243: if (LayerTreeHost::CreateFailedButTryAgain ==
result) {
style nit: please do if (variable == ConstantValue) throughout this CL. (also
saw this in SchedulerStateMachine)

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:251: const RendererCapabilities&
ThreadProxy::GetRendererCapabilities() const {
Can you add a DCHECK(IsMainThread()) in here?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:288: CheckOutputSurfaceStatusOnImplThread();
Don't change this. We want the DidLose stuff to happen outside the callback from
the GraphicsContext3d.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:335: DCHECK(vsync_client_);
Why? It seems like passing NULL is valid according to the line below, to disable
VsyncNotification

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:561: if (had_output_surface_initialized_)
can this be if(layer_tree_host_impl_->renderer())?

This variable is a main thread variable. using it here without locks is not
great.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:671: if (!layer_tree_host_->HasOutputSurface()) {
How can this be false? In the readback case, we called InitRendererIfNeeded().
In the non-readback case, we don't schedule begin frame while the surface is
lost.

Can this if block just go away? Feel free to dcheck !output_surface_lost_ in
LTH::UpdateLayers() if you want..

If this can go away, I think the LTH::HasOutputSurface() method can go away as
well (once LTH::had_output_surface_ goes too).

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1100: void ThreadProxy::InitializeContextOnImplThread(
s/Context/OutputSurface/

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.h
File cc/trees/thread_proxy.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.h#...
cc/trees/thread_proxy.h:197: bool had_output_surface_initialized_;
has_renderer_capabilities_on_main_thread?

[boliu, 2013-04-22 23:32:05]

Addressed all somments except no new tests yet. Going to first check if this
broke linux_chromeos even more.

I think we can call renderer in LTHI, and output surface everywhere else.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:184: if (output_surface_state_ ==
OUTPUT_SURFACE_LOST && can_begin_frame_)
On 2013/04/22 18:03:41, danakj wrote:
> We should follow up with a rename for this variable, and the whole
> SetSurfaceReady() thing, I think. This is "embedder ready" or "lth client
ready"
> really.

Renamed this from Scheduler down to SetCanStart. Also removed the param, since
nothing calls it with false.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:197: ((visible_ && can_begin_frame_) ||
needs_forced_commit_))
On 2013/04/22 18:03:41, danakj wrote:
> Do you need can_begin_frame_ here? How about checking OUTPUT_SURFACE_ACTIVE
> instead? Since now, O_S_LOST doesn't imply that we report BEGIN_O_S_CREATION
> anymore.

Both done.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:429: if (had_output_surface_)
On 2013/04/22 18:03:41, danakj wrote:
> This variable gets set true here, then stays true forever. So, we're
> SetNeedsCommit() when we create the first output surface, but not when we
> ecreate after a loss?

Wait, it should be the exact opposite. We are not setting need commit on first
output surface create, but do set it on all recreates after.

> Why is that?

This is to match old behavior, where first init used to be outside of scheduler
creation and did not SetNeedsCommit.

Also note that LTH::DidStartOutputSurfaceCreation (name in current PS), it also
calls SetNeedsCommit. These are duplicates but I'm guessing single_thread_proxy
needs the LTH call. But there are also implications for deleting this line too,
so I'm not sure if anything should be done about this.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.h:142: void DidCreateOutputSurface();
On 2013/04/22 18:03:41, danakj wrote:
> nit: DidCreateAndInitializeOutputSurface?

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.h:143: bool HasOutputSurface() const;
On 2013/04/22 18:03:41, danakj wrote:
> nit: HasInitializedOutputSurface?

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine_unittest.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:387:
state.DidCreateOutputSurface();
On 2013/04/22 18:03:41, danakj wrote:
> Should you just do this CanBeginFrame/CreateOutputSurface dance once at the
> start of the test? The surface isn't being lost in this test.

A new state machine is created in each loop. I don't think I can move this any
earlier.

Are you proposing re-using the same object in each loop?

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:724:
state.UpdateState(state.NextAction());
On 2013/04/22 18:03:41, danakj wrote:
> Can you add a unit test that verifies NextAction() is what we expect it to be
> before calling UpdateState() like this? And that NextAction() changes
> appropriately then after DidCreateOS()?

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:729:
state.DidLoseOutputSurface();
On 2013/04/22 18:03:41, danakj wrote:
> Can you verify what NextAction() is before calling DidLoseOS()? So we can see
it
> changes to BEGIN_O_S_CREATION afterward.

Verify it's not BEGIN_O_S_CREATION

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:756:
state.DidLoseOutputSurface();
On 2013/04/22 18:03:41, danakj wrote:
> Same here please verify NextAction()

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/test/fake_proxy.h
File cc/test/fake_proxy.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/test/fake_proxy.h#new...
cc/test/fake_proxy.h:20: void SetHost(LayerTreeHost* host);
On 2013/04/22 18:03:41, danakj wrote:
> nit: SetLayerTreeHost

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/test/fake_proxy.h#new...
cc/test/fake_proxy.h:50: LayerTreeHost* host_;
On 2013/04/22 18:03:41, danakj wrote:
> nit: layer_tree_host_

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:86: had_output_surface_(false),
On 2013/04/22 18:03:41, danakj wrote:
> I'd like this variable to go away, and I think it's possible. I've commented
at
> each site what I think could replace it.

Done. Had to fix some tests but had_output_surface_ is no more.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:87: output_surface_lost_(false),
On 2013/04/22 18:03:41, danakj wrote:
> Should this start true now? Then HasOutputSurface() can just check this
> variable.

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:126: return true;
On 2013/04/22 18:03:41, danakj wrote:
> If this is always true, then the method should not return a bool, and
> LTH::Create() should never return NULL.
> 
> That might be a rather large change of it's own, touching embedders etc, so
> probably makes sense as a followup patch.

Left a TODO

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:158: client_->DidRecreateOutputSurface(true);
On 2013/04/22 18:03:41, danakj wrote:
> It would make unit testing better if this was called always, but I realize
that
> might mess with the current embedder implementations. Did you try it?

Android and ui compositors are no-ops, render widget only calls out to webkit if
it failed so safe from embedder persective.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:175: if (!had_output_surface_) {
On 2013/04/22 18:03:41, danakj wrote:
> How about if (!contents_texture_manager) {} ?

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:194: } else {
On 2013/04/22 18:03:41, danakj wrote:
> No need for else when the if block returned.

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:196: client_->WillRetryRecreateOutputSurface();
On 2013/04/22 18:03:41, danakj wrote:
> Rename this WillRetryCreateOutputSurface() and call this always here. It will
> help you unit test failure recovery during the first initialization.

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:202: if (!had_output_surface_ ||
num_failed_recreate_attempts_ > 5) {
On 2013/04/22 18:03:41, danakj wrote:
> What is the advantage of unifying this code if we don't allow it to retry the
> same way? I don't think we want the !had_output_surface_ here.

Done. My original thought was don't introduce additional behavior changes, but
this patch already is a mix bag of changes.

This change might break more linux_chromeos tests. I was told that it is
intentional to have the renderer compositor fail on linux_chromeos. This will
delay the failure message by 5 retries.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:221: if (had_output_surface_)
On 2013/04/22 18:03:41, danakj wrote:
> how about just if (contents_texture_manager_)

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:503: if (had_output_surface_) {
On 2013/04/22 18:03:41, danakj wrote:
> if (!output_surface_lost_) ?

This depends on output_surface_lost_ defaulting to true. Done

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:525: if (!had_output_surface_)
On 2013/04/22 18:03:41, danakj wrote:
> I think this if can just go away. The LTHI will early out as appropriate.
> 
> (And it would be nice to minimize our dependence on had_output_surface_ so we
> can see what is really depending on it)

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.h:125: CreateResult OnCreateAttempted(bool success);
On 2013/04/22 18:03:41, danakj wrote:
> OnCreateAndInitializeOutputSurfaceAttempted()

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:984:
context3d_->set_have_extension_io_surface(true);
On 2013/04/22 18:03:41, danakj wrote:
> nit: how about output_surface->Context3d()->set_have...

These are methods on the test context, so need to do a cast. I think not
changing this is safer.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:103: void
SingleThreadProxy::CreateAndInitializeOutputSurface() {
On 2013/04/22 18:03:41, danakj wrote:
> Why doesn't this call DidStartOutputSurfaceCreation() like the thread proxy?
> Should we test that?

I think it's because single thread proxy recreates output surface as a result of
SetNeedsCommit, so there is no need to call SetNeedsCommit again. Also there is
no retry on failure logic.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:130:
layer_tree_host_->DeleteContentsTexturesOnImplThread(
On 2013/04/22 18:03:41, danakj wrote:
> I don't think this needs to be inside the if(had_renderer_caps) block. LTH
does
> the right thing. And this implicitly ties the proxy
"had_renderer_capabilities"
> to state in the LTH which I dislike. Can we just call this always when we get
> this far? Maybe do this just before InitializeRenderer()?

Done.

Also removed the had_renderer_capabilities check above since it's redundant as
well.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:147: if (had_renderer_capabilities) {
On 2013/04/22 18:03:41, danakj wrote:
> I think this if() isn't serving much purpose, can we remove it and just call
> set_offscreen_c_p() always here? We'll always have one thanks to the early-out
> above if we're supposed to have one. And setting it to NULL when we don't is
> fine.

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:151: } else if (had_renderer_capabilities &&
offscreen_context_provider) {
On 2013/04/22 18:03:41, danakj wrote:
> else if(offscreen_context_provider) is enough.

Done.

With all the clean up in this function, it looks a lot like
ThreadProxy::InitializeContextOnImplThread (name in this PS). Is it a good idea
to try to move this into the common superclass?

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:182: void ThreadProxy::DoCreateAndInitializeContext() {
On 2013/04/22 18:03:41, danakj wrote:
> s/Context/OutputSurface/
> 
> This "Context" reference is a hold-over from before we had output surfaces.

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:191: scoped_refptr<ContextProvider>
offscreen_context_provider;
On 2013/04/22 18:03:41, danakj wrote:
> Move this below the early out if it's not used

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:230: void ThreadProxy::OnContextInitializeAttempted(
On 2013/04/22 18:03:41, danakj wrote:
> s/Context/OutputSurface/

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:243: if (LayerTreeHost::CreateFailedButTryAgain ==
result) {
On 2013/04/22 18:03:41, danakj wrote:
> style nit: please do if (variable == ConstantValue) throughout this CL. (also
> saw this in SchedulerStateMachine)

Done.

For reference, my habit of doing ConstValue == var comes from safety of not
being able to mistakely miss an equal sign and make it an assignment.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:251: const RendererCapabilities&
ThreadProxy::GetRendererCapabilities() const {
On 2013/04/22 18:03:41, danakj wrote:
> Can you add a DCHECK(IsMainThread()) in here?

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:288: CheckOutputSurfaceStatusOnImplThread();
On 2013/04/22 18:03:41, danakj wrote:
> Don't change this. We want the DidLose stuff to happen outside the callback
from
> the GraphicsContext3d.

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:335: DCHECK(vsync_client_);
On 2013/04/22 18:03:41, danakj wrote:
> Why? It seems like passing NULL is valid according to the line below, to
disable
> VsyncNotification

My bad, this was for debugging weeks ago. Removed.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:561: if (had_output_surface_initialized_)
On 2013/04/22 18:03:41, danakj wrote:
> can this be if(layer_tree_host_impl_->renderer())?
> 
> This variable is a main thread variable. using it here without locks is not
> great.

Moved the if check into main thread function above, then change this to
renderer().

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:671: if (!layer_tree_host_->HasOutputSurface()) {
On 2013/04/22 18:03:41, danakj wrote:
> How can this be false? In the readback case, we called InitRendererIfNeeded().
> In the non-readback case, we don't schedule begin frame while the surface is
> lost.
> 
> Can this if block just go away? Feel free to dcheck !output_surface_lost_ in
> LTH::UpdateLayers() if you want..
> 
> If this can go away, I think the LTH::HasOutputSurface() method can go away as
> well (once LTH::had_output_surface_ goes too).

All true. Done done done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1100: void ThreadProxy::InitializeContextOnImplThread(
On 2013/04/22 18:03:41, danakj wrote:
> s/Context/OutputSurface/

Done.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.h
File cc/trees/thread_proxy.h (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/thread_proxy.h#...
cc/trees/thread_proxy.h:197: bool had_output_surface_initialized_;
On 2013/04/22 18:03:41, danakj wrote:
> has_renderer_capabilities_on_main_thread?

James suggested that has_cap makes no sense after output surface is lost.

[boliu, 2013-04-23 01:46:35]

On 2013/04/22 18:03:41, danakj wrote:
> Can you add some tests for the new code paths? Specifically:
> 1. If the context is lost twice during the first initialization, that the
> compositor still comes up and can produce frames after (but not before).

This is LayerTreeHostContextTestFailsFirstInitialization, rewritten from
LayerTreeHostContextTestFailsImmediately that was expecting immediate failure
before.

> 2. If the context is lost many times during the first initialization, the
> compositor fails and reports DidCreateOutputSurface(false) to its client.

Covered by LayerTreeHostContextTestRetriesFirstInitializationAndSucceeds

Also added LayerTreeHostContextTestRetryWorksWithForcedInit that mixes
InitializeOutputSurfaceIfNeeded during a recreate. A bit pathological but not
impossible given the LTHClient api.

[danakj, 2013-04-23 18:22:39]

Looking good, LTH is a lot cleaner now. I think there's a bit we can do in the
proxies still, but I like this direction a lot.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:429: if (had_output_surface_)
On 2013/04/22 23:32:05, boliu wrote:
> On 2013/04/22 18:03:41, danakj wrote:
> > This variable gets set true here, then stays true forever. So, we're
> > SetNeedsCommit() when we create the first output surface, but not when we
> > ecreate after a loss?
> 
> Wait, it should be the exact opposite. We are not setting need commit on first
> output surface create, but do set it on all recreates after.

Oh, I misread that!

> > Why is that?
> 
> This is to match old behavior, where first init used to be outside of
scheduler
> creation and did not SetNeedsCommit.
> 
> Also note that LTH::DidStartOutputSurfaceCreation (name in current PS), it
also
> calls SetNeedsCommit. These are duplicates but I'm guessing
single_thread_proxy
> needs the LTH call. But there are also implications for deleting this line
too,
> so I'm not sure if anything should be done about this.

Ya, DidStartOutputSurfaceCreation causes a commit in order to make sure the
single thread proxy does its recreation since the embedder doesn't keep track of
anything really beyond "needs composite".

I guess the point here is that you are not allowed to begin frame until you've
created/init one output surface+renderer. So there's nothing that needs to be
re-committed after its created for the first time.

I think once we get impl-side painting on all the time, maybe the main thread
won't have to do any work when the renderer/surface changes, and we can just
remove this SetNeedsCommit().

I'm sad to see another bool in this already-too-many-bools class. But I also am
not sure how to remove it without adding a useless SetNeedsCommit() during
startup.

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine_unittest.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine_unittest.cc:387:
state.DidCreateOutputSurface();
On 2013/04/22 23:32:05, boliu wrote:
> On 2013/04/22 18:03:41, danakj wrote:
> > Should you just do this CanBeginFrame/CreateOutputSurface dance once at the
> > start of the test? The surface isn't being lost in this test.
> 
> A new state machine is created in each loop. I don't think I can move this any
> earlier.
> 
> Are you proposing re-using the same object in each loop?

Oh, I didn't notice that :) Never mind my comment here.

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/105001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:151: } else if (had_renderer_capabilities &&
offscreen_context_provider) {
On 2013/04/22 23:32:05, boliu wrote:
> On 2013/04/22 18:03:41, danakj wrote:
> > else if(offscreen_context_provider) is enough.
> 
> Done.
> 
> With all the clean up in this function, it looks a lot like
> ThreadProxy::InitializeContextOnImplThread (name in this PS). Is it a good
idea
> to try to move this into the common superclass?

I wanna say no, this class is going to just be deleted at some point, and there
may be subtle differences, and debug scoping things.

https://codereview.chromium.org/12544032/diff/129001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/129001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:431: had_output_surface_ = true;
nit: did_create_and_initialize_first_output_surface_

https://codereview.chromium.org/12544032/diff/129001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.h (right):

https://codereview.chromium.org/12544032/diff/129001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.h:125: // Indicates whether we can
successfully begin a frame at this time.
This comment needs updating

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:162: client_->DidRecreateOutputSurface(true);
nit: let's move this down just before the return, same as the failure path, so
we do all our work before telling the client.

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:189: settings_.default_tile_size = gfx::Size(
fyi these two settings will be no longer be changed by the renderer caps on tot.

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:205: if (++num_failed_recreate_attempts_ >= 5) {
one statement per line. do the ++ on a separate line as before please.

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:212: // FIXME: The single thread does not
self-schedule output surface
Should we move this to the single thread proxy now to do when we return
TryAgain?

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:506: if (!output_surface_lost_) {
if (output_surface_lost_) return; will avoid nesting.

https://codereview.chromium.org/12544032/diff/133002/cc/scheduler/scheduler.h
File cc/scheduler/scheduler.h (right):

https://codereview.chromium.org/12544032/diff/133002/cc/scheduler/scheduler.h...
cc/scheduler/scheduler.h:94: void DidCreateAndInitializeOutputSurface();
Since this is impl, should these be mentioning the Renderer in their names?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:61: times_to_expect_failure_(0),
nit: times_to_expect_create_failed

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:62: times_failed_(0),
nit: times_create_failed

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:157: if (!frame->has_no_damage)
Hm, can we just always EXPECT_TRUE here? I'm now fuzzy why this was expecting
false when there's no damage. Was the old check failing?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:204: void ExpectRecreateToRetry() {
ExpectCreateToFail()?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:244: // This is called on first
create as well.
This will be clear when the function is renamed, I think you don't need the
comment here.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:248: if (first_initialized_) {
no {} needed for these

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:649: first_initialized_(false) {
You could init this in BeginTest() and avoid the constructor if you want (it
adds so many lines of boilerplate - just the pattern I've started following), or
leave it as is if you prefer.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1010:
context3d_->set_have_extension_io_surface(true);
How about setting the set_have_extension_io_surface etc in
LTHContextTest::CreateOutputSurface() when it makes the TestWGC3D if some
variable context_should_support_io_surface_ in the base class is true? Then have
this class set that variable. This function could go away.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1135: class
LayerTreeHostContextTestFailsFirstInitialization
Can you add a DidCommitAndDrawFrame() method in this test that will
EXPECT_FALSE(true), ie fail the test, if it's called?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1149: virtual
scoped_ptr<TestWebGraphicsContext3D> CreateContext3d() OVERRIDE {
Remove this function, set times_to_lose_on_create_ = 1000 in BeginTest() and you
should have the same thing, I think, without having to tweak
times_to_expect_failure_ in DidRecreateOS().

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1185: times_to_expect_failure_ = 2;
You should get this for free, the times_to_fail_initialize_ path will set this
expectation.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1202:
layer_tree_host()->InitializeOutputSurfaceIfNeeded();
This isn't really supposed to be public API for LTH. Can you do the same thing
by calling CompositeAndReadback instead? (Won't need SetNeedsRedraw either)

https://codereview.chromium.org/12544032/diff/133002/cc/trees/proxy.h
File cc/trees/proxy.h (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/proxy.h#newcode62
cc/trees/proxy.h:62: // Attempts to recreate the context and layer renderer
synchronously after a
Hah "layer renderer" this is an old comment. Just "renderer", it's cleaner.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/proxy.h#newcode63
cc/trees/proxy.h:63: // context lost. Calls LayerTreeHost::OnCreateAttemped with
the result.
"after the output surface is lost"

https://codereview.chromium.org/12544032/diff/133002/cc/trees/proxy.h#newcode63
cc/trees/proxy.h:63: // context lost. Calls LayerTreeHost::OnCreateAttemped with
the result.
"OnCreateAttempted()" needs to be updated

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:28: output_surface_lost_(false),
default this to true

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:30: had_output_surface_initialized_(false),
This variable is problematic for the future, the same way as it was in LTH. It
creating assumptions that "once we initialize the renderer one way, things will
stay that way for the future, across context loss etc. We want to move away from
that world. I think we can remove this variable as well, and commented at its
use sites.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:156: DCHECK(had_output_surface_initialized_);
Can you dcheck !output_surface_lost_ instead? We care more about "we have valid
caps right now" than "we got caps once so we're good forever now"

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:157: // Note: this gets called during the commit
by the "impl" thread.
Hmmmm.. is this true? We added an assert IsMainThread() here in the ThreadProxy.
I think this is a lie, I can't see the callsite. Can you remove this note and
add an assert here as well?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:351: if (had_output_surface_initialized_)
if (!output_surface_lost_) ?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:440:
layer_tree_host_->DidStartOutputSurfaceCreation();
I'm not sure about this rename.. really we want to tell the host it was lost
here. Maybe we can mimic the behaviour of the thread proxy better here?
SetNeedsCommit() directly here instead of doing it in DidStartOSCreation(), and
call DidStartOSCreation() from CreateAndInitOutputSurface instead?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:255: DCHECK(had_output_surface_initialized_);
i'd like this to be an explicit variable the says if the renderer caps are valid
(ie the context is lost/renderer isn't initialized yet) for the main thread to
use. for the same reasons as stated in the single thread proxy. IOW when the
surface is lost, this variable should become false.

You mentioned something james had said so maybe we're disagreeing about this?
I'm not sure, can you elaborate?

I just feel that dchecking "we initialized the renderer once" is far less useful
than "we have an initialized renderer and these are the caps for it" because in
the future, the caps may change when we re-init the renderer.

The lost context code never actually goes to the main thread however, where it
could reset this variable. Since this is just a dcheck, maybe it would make
sense to #ifndef NDEBUG make a hop to the impl thread and verify that
scheduler->HasInitializedOutputSurface() is true? Then this variable can go
away.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:554: if (had_output_surface_initialized_) {
if (!___) return;

Same comment here about this variable, it should be true when we have a valid
context/surface/renderer on the impl thread that we can use. Not true forever
once we've initialized a renderer once.

In this case it's just going to hop to the impl thread, so maybe this is not
needed. The impl thread can just DoNoOp() on a lost context and nothing bad will
happen. So I'd vote to just remove this check.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:845: void
ThreadProxy::ScheduledActionBeginContextCreation() {
s/Context/OutputSurface/

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.h
File cc/trees/thread_proxy.h (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.h#...
cc/trees/thread_proxy.h:133: 
drop the newline, make it clear this is part of the main thread block of
functions

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.h#...
cc/trees/thread_proxy.h:134: // |capabilities| is set only on
INIT_SUCCESSFUL_AND_COMPLETE.
what is INIT_SUCCESSFUL_AND_COMPLETE?

[danakj, 2013-04-23 18:34:00]

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:255: DCHECK(had_output_surface_initialized_);
On 2013/04/23 18:22:40, danakj wrote:
> i'd like this to be an explicit variable the says if the renderer caps are
valid
> (ie the context is lost/renderer isn't initialized yet) for the main thread to
> use. for the same reasons as stated in the single thread proxy. IOW when the
> surface is lost, this variable should become false.
> 
> You mentioned something james had said so maybe we're disagreeing about this?
> I'm not sure, can you elaborate?
> 
> I just feel that dchecking "we initialized the renderer once" is far less
useful
> than "we have an initialized renderer and these are the caps for it" because
in
> the future, the caps may change when we re-init the renderer.
> 
> The lost context code never actually goes to the main thread however, where it
> could reset this variable. Since this is just a dcheck, maybe it would make
> sense to #ifndef NDEBUG make a hop to the impl thread and verify that
> scheduler->HasInitializedOutputSurface() is true? Then this variable can go
> away.

I spoke with james a bit about this, cuz I was not really sure I was a fan of
the thread hop suggestion. He agreed that the thread hop, or signalling back to
the main thread immediately on context loss, just for a dcheck are not really
great.

So, let's have this variable that we're DCHECKing here be false to start with,
true when we create a surface/renderer successfully, and false when we start the
recreation process again (ie when CreateAndInitOutputSurface happens). It'll
give us some coverage at least and can't be racy.

[boliu, 2013-04-24 01:28:52]

If I didn't have a reply, interpret as "Done". Now the reply is actually short
enough to read.

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:189: settings_.default_tile_size = gfx::Size(
On 2013/04/23 18:22:40, danakj wrote:
> fyi these two settings will be no longer be changed by the renderer caps on
tot.

Rebased and removed this.

https://codereview.chromium.org/12544032/diff/129001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:212: // FIXME: The single thread does not
self-schedule output surface
On 2013/04/23 18:22:40, danakj wrote:
> Should we move this to the single thread proxy now to do when we return
> TryAgain?

Done.

Added SingleThreadProxy::OnOutputSurfaceInitializeAttempted to dedup code. Also
not calling SetNeedsCommit directly (not LTH one) so no longer cancelling
prepaint_callback_. I think this is ok.

https://codereview.chromium.org/12544032/diff/133002/cc/scheduler/scheduler.h
File cc/scheduler/scheduler.h (right):

https://codereview.chromium.org/12544032/diff/133002/cc/scheduler/scheduler.h...
cc/scheduler/scheduler.h:94: void DidCreateAndInitializeOutputSurface();
On 2013/04/23 18:22:40, danakj wrote:
> Since this is impl, should these be mentioning the Renderer in their names?

Err...do I have to? How about let's make the rule to only mention renderer in
LTHI methods. There is GetRendererCap but that's kind of an exception...

Didn't do anything for this.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:157: if (!frame->has_no_damage)
On 2013/04/23 18:22:40, danakj wrote:
> Hm, can we just always EXPECT_TRUE here? I'm now fuzzy why this was expecting
> false when there's no damage. Was the old check failing?

Having unconditional EXPECT_TRUE(result) is ok.

Old check was failing in LayerTreeHostContextTestRetryWorksWithForcedInit where
there is an extra SetNeedsCommit for single_thread_proxy that ended up having no
damage.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:649: first_initialized_(false) {
On 2013/04/23 18:22:40, danakj wrote:
> You could init this in BeginTest() and avoid the constructor if you want (it
> adds so many lines of boilerplate - just the pattern I've started following),
or
> leave it as is if you prefer.

No boilerplate sounds better to me.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1149: virtual
scoped_ptr<TestWebGraphicsContext3D> CreateContext3d() OVERRIDE {
On 2013/04/23 18:22:40, danakj wrote:
> Remove this function, set times_to_lose_on_create_ = 1000 in BeginTest() and
you
> should have the same thing, I think, without having to tweak
> times_to_expect_failure_ in DidRecreateOS().

times_to_lose_on_create_ works.

ExpectCreateToFail checks committed_at_least_once_ before incrementing, which is
wrong. Removing the check breaks LayerTreeHostContextTestOffscreenContextFails,
so move the tweak there since failing to create first offscreen context is *not*
an error. Remove tweak here.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1202:
layer_tree_host()->InitializeOutputSurfaceIfNeeded();
On 2013/04/23 18:22:40, danakj wrote:
> This isn't really supposed to be public API for LTH. Can you do the same thing
> by calling CompositeAndReadback instead? (Won't need SetNeedsRedraw either)

Had to include SkBitmap to call CompositeAndReadback. Please check my usage as
it's my first time using skia classes.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:30: had_output_surface_initialized_(false),
On 2013/04/23 18:22:40, danakj wrote:
> This variable is problematic for the future, the same way as it was in LTH. It
> creating assumptions that "once we initialize the renderer one way, things
will
> stay that way for the future, across context loss etc. We want to move away
from
> that world. I think we can remove this variable as well, and commented at its
> use sites.

Using copy in LTH. See my reply in thread_proxy.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:440:
layer_tree_host_->DidStartOutputSurfaceCreation();
On 2013/04/23 18:22:40, danakj wrote:
> I'm not sure about this rename.. really we want to tell the host it was lost
> here. Maybe we can mimic the behaviour of the thread proxy better here?
> SetNeedsCommit() directly here instead of doing it in DidStartOSCreation(),
and
> call DidStartOSCreation() from CreateAndInitOutputSurface instead?

Moving this to CreateAndInitOutputSurface will break retry on failure logic
since DidStartOSCreation resets the retry counter. At least this behavior is
similar to ThreadProxy, that DidStartOSCreation is only called only on context
lost *after* successful initialzation, not on each retry.

I think renaming this back to DidLoseOutputSurface is probably the easier
solution.

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:255: DCHECK(had_output_surface_initialized_);
So now both single_thread_proxy and this effectively have a copy of
LTH::output_surface_lost_. Going to add LTH::output_surface_lost() instead, just
for DCHECKing in the proxies.

This more tightly couples LTH and the proxies, but I think it's worth it,
thoughts?

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.h
File cc/trees/thread_proxy.h (right):

https://codereview.chromium.org/12544032/diff/133002/cc/trees/thread_proxy.h#...
cc/trees/thread_proxy.h:134: // |capabilities| is set only on
INIT_SUCCESSFUL_AND_COMPLETE.
On 2013/04/23 18:22:40, danakj wrote:
> what is INIT_SUCCESSFUL_AND_COMPLETE?

Should be |success| is true.

[danakj, 2013-04-24 15:38:42]

I love it :) There's one if() in thread proxy which I think is always false
right now? A few nits left, but I'm super happy about this.

James, want to have a look?

LGTM once that if() question is sorted out.

https://codereview.chromium.org/12544032/diff/151001/cc/scheduler/scheduler_s...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/scheduler/scheduler_s...
cc/scheduler/scheduler_state_machine.cc:429: if
(did_create_and_initialize_first_output_surface_)
Can you stick a TODO in here so we can remember to come back to this one day:
"See if we can remove this when impl-side painting is always on. Does anything
on the main thread need to update after recreate?"

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1134:
LayerTreeHostContextTestFailsFirstInitialization()
nit: useless constructor/destructor can go away (shouldnt be there in the first
place)

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1164:
LayerTreeHostContextTestRetriesFirstInitializationAndSucceeds()
constructor can go away

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1185:
LayerTreeHostContextTestRetryWorksWithForcedInit()
and this one

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1202:
layer_tree_host()->CompositeAndReadback(bitmap.getPixels(), rect);
You can just do this and avoid all the SkBitmap stuff, taken from
lth_unittest.cc:

char pixels[4];
layer_tree_host()->CompositeAndReadback(&pixels, gfx::Rect(1, 1));


If you want to use the bitmap you did it right but:
- omit the 4th argument to setConfig()
- call bitmap.lockPixels() and unlockPixels() before/after the
CompositeAndReadback().

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:184: DCHECK(layer_tree_host_);
Not sure why this dcheck, the lth is part of the constructor here. If anything
do this in the constructor.

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:209: // Make a blocking call to
RecreateOutputSurfaceOnImplThread. The results of
fix the name in this comment

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:210: // that call are pushed into the
recreate_succeeded and capabilities local
s/recreate_succeeded/success/

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1109: if
(scheduler_on_impl_thread_->HasInitializedOutputSurface()) {
Will this if() eever be true currently?

If we ever succeed, we reset the callback, which causes DoCreateAndInitOS() to
not be called again. I feel like this is a remnant of the async patch, or is it
needed for something else?

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.h
File cc/trees/thread_proxy.h (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.h#...
cc/trees/thread_proxy.h:203: 
nit: extraneous whitespace

[boliu, 2013-04-24 17:48:19]

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1202:
layer_tree_host()->CompositeAndReadback(bitmap.getPixels(), rect);
On 2013/04/24 15:38:42, danakj wrote:
> char pixels[4];
> layer_tree_host()->CompositeAndReadback(&pixels, gfx::Rect(1, 1));

This sounds way better. Also added EXPECT_FALSE to CompositeAndReadback since
recreate is supposed to fail here

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:184: DCHECK(layer_tree_host_);
On 2013/04/24 15:38:42, danakj wrote:
> Not sure why this dcheck, the lth is part of the constructor here. If anything
> do this in the constructor.

This is DCHECK-ing that Stop has not been called. After Stop, scheduler no
longer exists, which means this can only be called from CompositeAndReadback,
which already has a DCHECK for LTH. So yep, moving to constructor.

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1109: if
(scheduler_on_impl_thread_->HasInitializedOutputSurface()) {
On 2013/04/24 15:38:42, danakj wrote:
> Will this if() eever be true currently?
> 
> If we ever succeed, we reset the callback, which causes DoCreateAndInitOS() to
> not be called again. I feel like this is a remnant of the async patch, or is
it
> needed for something else?

Yes this is needed to prevent re-initializing everything when the output surface
is already active (ie DCHECK in scheduler DidCreateAndInitializeOutputSurface)

This is failing in LayerTreeHostTestDeviceScaleFactorScalesViewportAndLayers
(and possibly other tests) which calls LTH::InitializeOutputSurfaceIfNeeded
immediately after SetSurfaceReady in the same call stack. The flow goes like
this:

* SetSurfaceReady leads to scheduler posting a task to main thread to
CreateAndInitializeOutputSurface
* While this task is waiting in the queue, LTH::InitializeOutputSurfaceIfNeeded
is called, successfully initializes output surface, advances scheduler to
OUTPUT_SRUFACE_ACTIVE, and cancels the task.
* CreateAndInitializeOutputSurface finally runs, resets the task, tell LTH that
output surface is lost (even though it is not), and the proceeds to create
again, and trips into this.

Idealy we would be able to tell in CreateAndInitializeOutputSurface that between
when it was scheduled and run, the output surface is recreated so there is no
need to run again. So...make this a cancelable task and to be cancelled here if
succeeds? I don't know if it can be used across threads like that?

(Didn't do anything in this patch set)

[danakj, 2013-04-24 20:43:01]

https://codereview.chromium.org/12544032/diff/158001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/158001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:247: output_surface_creation_callback_.Cancel();
Should we Cancel() if CreateFailedAndGiveUp too?

I'm thinking about the bug for https://codereview.chromium.org/14238011/ what if
we get the ordering like:

- Lose context
- DoCreateAndInit fails -> retry x1
- DoCreateAndInit fails -> retry x2
- DoCreateAndInit fails -> retry x3
- DoCreateAndInit fails -> retry x4
- DoCreateAndInit is post-tasked here.
- CompositeAndReadback comes here, tries to init fails. That's the 5th failure,
we DidRecreateOS(false) to the embedder.
- DoCreateAndInit wakes up and runs, and succeeds.

Now the compositor and the embedder disagree on things.

[danakj, 2013-04-24 21:01:00]

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1109: if
(scheduler_on_impl_thread_->HasInitializedOutputSurface()) {
On 2013/04/24 17:48:20, boliu wrote:
> On 2013/04/24 15:38:42, danakj wrote:
> > Will this if() eever be true currently?
> > 
> > If we ever succeed, we reset the callback, which causes DoCreateAndInitOS()
to
> > not be called again. I feel like this is a remnant of the async patch, or is
> it
> > needed for something else?
> 
> Yes this is needed to prevent re-initializing everything when the output
surface
> is already active (ie DCHECK in scheduler DidCreateAndInitializeOutputSurface)
> 
> This is failing in LayerTreeHostTestDeviceScaleFactorScalesViewportAndLayers
> (and possibly other tests) which calls LTH::InitializeOutputSurfaceIfNeeded
> immediately after SetSurfaceReady in the same call stack. The flow goes like
> this:
> 
> * SetSurfaceReady leads to scheduler posting a task to main thread to
> CreateAndInitializeOutputSurface
> * While this task is waiting in the queue,
LTH::InitializeOutputSurfaceIfNeeded
> is called, successfully initializes output surface, advances scheduler to
> OUTPUT_SRUFACE_ACTIVE, and cancels the task.
> * CreateAndInitializeOutputSurface finally runs, resets the task, tell LTH
that
> output surface is lost (even though it is not), and the proceeds to create
> again, and trips into this.

Hm, that sounds awkward. Does that leave the LTH with output_surface_lost_ =
true in the end? This is also just bad test behaviour..

If I remove this from the test you cite:

-    ASSERT_TRUE(layer_tree_host()->InitializeRendererIfNeeded());
-    ResourceUpdateQueue queue;
-    layer_tree_host()->UpdateLayers(&queue,
std::numeric_limits<size_t>::max());

The test passes fine still, and I don't see why that is there at all! It's super
weird to call UpdateLayers() directly from a LTH test.

We should fix the tests that hit this path I think rather than coding support
for it into the proxy, if possible. Can you take a look at the other tests, or
post a list of them? I can help out if you like.

> Idealy we would be able to tell in CreateAndInitializeOutputSurface that
between
> when it was scheduled and run, the output surface is recreated so there is no
> need to run again. So...make this a cancelable task and to be cancelled here
if
> succeeds? I don't know if it can be used across threads like that?
> 
> (Didn't do anything in this patch set)

[boliu, 2013-04-24 22:01:00]

Question: Now we retry 5 times before stopping. What if the error is in
CreateOutputSurface failing to create the WGC3D. In this case, we will try to
create a new GPU process 5 times.

We are hitting this pathological case on linux_chromeos try bot, were gl
initialization fails. Now we are telling render widget/host accelerated
compositing is enabled while waiting for 5 failures. This is causing some
flakiness on integration tests on the bot due to this addional churn.

Also in this case, render widget never used to send accelerated compositing
enabled message to the host, which is also causing some linux_chromeos tests to
fail (crbug.com/234042)

I know these are really test issues, they are blocking this from landing. Should
we re-evaluate if we should be retrying on this case?

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1109: if
(scheduler_on_impl_thread_->HasInitializedOutputSurface()) {
On 2013/04/24 21:01:00, danakj wrote:
> Hm, that sounds awkward. Does that leave the LTH with output_surface_lost_ =
> true in the end?

Nope, we are setting *success = true here.

> This is also just bad test behaviour..
> 
> If I remove this from the test you cite:
> 
> -    ASSERT_TRUE(layer_tree_host()->InitializeRendererIfNeeded());
> -    ResourceUpdateQueue queue;
> -    layer_tree_host()->UpdateLayers(&queue,
> std::numeric_limits<size_t>::max());
> 
> The test passes fine still, and I don't see why that is there at all! It's
super
> weird to call UpdateLayers() directly from a LTH test.
> 
> We should fix the tests that hit this path I think rather than coding support
> for it into the proxy, if possible. Can you take a look at the other tests, or
> post a list of them? I can help out if you like.

So how does the embedder know when is it safe to call CompositeAndReadback? Is
this case impossible in practice?

Here's the rest of the list and how I fixed them:

* LayerTreeHostTestCompositeAndReadbackCleanup - Move test to
DidRecreateOutputSurface hook so CompositeAndReadback is not force initializing
output surface.
* LayerTreeHostTestCapturePicture - Remove InitializeOutputIfNeeded call,
nothing broke
* ScrollbarLayerTestMaxTextureSize - Remove InitializeOutputIfNeeded call,
nothing broke

https://codereview.chromium.org/12544032/diff/158001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/158001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:247: output_surface_creation_callback_.Cancel();
On 2013/04/24 20:43:01, danakj wrote:
> Should we Cancel() if CreateFailedAndGiveUp too?
> 
> I'm thinking about the bug for https://codereview.chromium.org/14238011/ what
if
> we get the ordering like:
> 
> - Lose context
> - DoCreateAndInit fails -> retry x1
> - DoCreateAndInit fails -> retry x2
> - DoCreateAndInit fails -> retry x3
> - DoCreateAndInit fails -> retry x4
> - DoCreateAndInit is post-tasked here.
> - CompositeAndReadback comes here, tries to init fails. That's the 5th
failure,
> we DidRecreateOS(false) to the embedder.
> - DoCreateAndInit wakes up and runs, and succeeds.
> 
> Now the compositor and the embedder disagree on things.

Done.

Maybe we should do something more drastic like stopping thread_proxy? I'm not
sure...

[danakj, 2013-04-24 23:17:13]

On 2013/04/24 22:01:00, boliu wrote:
> Question: Now we retry 5 times before stopping. What if the error is in
> CreateOutputSurface failing to create the WGC3D. In this case, we will try to
> create a new GPU process 5 times.
> 
> We are hitting this pathological case on linux_chromeos try bot, were gl
> initialization fails. Now we are telling render widget/host accelerated
> compositing is enabled while waiting for 5 failures. This is causing some
> flakiness on integration tests on the bot due to this addional churn.
> 
> Also in this case, render widget never used to send accelerated compositing
> enabled message to the host, which is also causing some linux_chromeos tests
to
> fail (crbug.com/234042)
> 
> I know these are really test issues, they are blocking this from landing.
Should
> we re-evaluate if we should be retrying on this case?

Hm, so turns out the return value from LTH::Create() is pretty important.

There's 2 scenarios:

1) The context creation fails. We should not retry and and LTH::Create() should
return false to match previous expectations and not try create GPU process over
and over.

2) The creation works but it gets lost quickly after before we can init the
renderer. We should retry in this case.

There used to be some logic in the proxies that held onto an OutputSurface* that
was created in LTH::Create() in order to make 1) happen. We could retain that by
having the proxy only call LTH::CreateOutputSurface when it doesn't have an
OutputSurface* already, provided from the LTH::Create() path.

Then, the first time you go to DoCreateAndInitOutputSurface, you could skip the
create step. The next time around it would be gone and youd have to
CreateOutputSurface() again.

What do you think of that?

> > I'm thinking about the bug for https://codereview.chromium.org/14238011/
what
> if
> > we get the ordering like:
> > 
> > - Lose context
> > - DoCreateAndInit fails -> retry x1
> > - DoCreateAndInit fails -> retry x2
> > - DoCreateAndInit fails -> retry x3
> > - DoCreateAndInit fails -> retry x4
> > - DoCreateAndInit is post-tasked here.
> > - CompositeAndReadback comes here, tries to init fails. That's the 5th
> failure,
> > we DidRecreateOS(false) to the embedder.
> > - DoCreateAndInit wakes up and runs, and succeeds.
> > 
> > Now the compositor and the embedder disagree on things.
> 
> Done.
> 
> Maybe we should do something more drastic like stopping thread_proxy? I'm not
> sure...

I think the solution to https://codereview.chromium.org/14238011/ can also apply
here. The DoCreateAndInit method should be verifying that the LTH hasn't told
its client that it's giving up on life before trying to init. The cancel solves
that for now (thanks) but we could DCHECK and early-out in DoCreateAndInit if
the LTH has already done DidRecreateOS(false). WDYT of that?

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/151001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1109: if
(scheduler_on_impl_thread_->HasInitializedOutputSurface()) {
On 2013/04/24 22:01:00, boliu wrote:
> So how does the embedder know when is it safe to call CompositeAndReadback? Is
> this case impossible in practice?

You're right it should be able to call it immediately. I didn't think of the
Comp&Readback case immediately after creation.

> 
> Here's the rest of the list and how I fixed them:
> 
> * LayerTreeHostTestCompositeAndReadbackCleanup - Move test to
> DidRecreateOutputSurface hook so CompositeAndReadback is not force
initializing
> output surface.

This one feels wrong, I guess we need to handle this case. I'm glad we have some
test coverage of this. I guess in this case we're going to end up calling
DidRecreateOutputSurface(true) an extra time for no reason too since we told LTH
it lost the context but actually didn't.. doh.

Cancellable callback is not threadsafe so it's not something we can use to solve
this unfortunately.

So the problem is basically impl side can tell main thread to create output
surface. By the time it gets to that task, it may have already done it, and how
can it tell. We need some kind of extra syncronization between threads. We could
use a lock and a variable or some kind to signal, but that's kinda ugly.

What if the first thing CreateAndInitializeOutputSurface() did was to block the
main thread and jump to the impl thread and query if we have an output surface.
And then if we do, just early out. That would remove race conditions with the
main thread doing it in between, and avoid an extra DidLose() and DidRecreate()
from going on.


> * LayerTreeHostTestCapturePicture - Remove InitializeOutputIfNeeded call,
> nothing broke
> * ScrollbarLayerTestMaxTextureSize - Remove InitializeOutputIfNeeded call,
> nothing broke

Those look fine to me.

[boliu, 2013-04-25 01:03:35]

On 2013/04/24 23:17:13, danakj wrote:
> 1) The context creation fails. We should not retry and and LTH::Create()
should
> return false to match previous expectations and not try create GPU process
over
> and over.
> 
> 2) The creation works but it gets lost quickly after before we can init the
> renderer. We should retry in this case.
> 
> There used to be some logic in the proxies that held onto an OutputSurface*
that
> was created in LTH::Create() in order to make 1) happen. We could retain that
by
> having the proxy only call LTH::CreateOutputSurface when it doesn't have an
> OutputSurface* already, provided from the LTH::Create() path.
> 
> Then, the first time you go to DoCreateAndInitOutputSurface, you could skip
the
> create step. The next time around it would be gone and youd have to
> CreateOutputSurface() again.
> 
> What do you think of that?

Unfortunate but seems necessary at this stage. Makes this patch less lovable.
And I think Vangelis was suggesting this could improve start up time:
https://code.google.com/p/chromium/issues/detail?id=230197#c4  Oh well...

Maybe a better long term solution would be to let embedder set how many times to
retry. It can start with 0 and RenderWidget can set it to 5 after first
OutputSurface created.

But should definitely fix linux_chromeos first though. It's relying on the fact
that we fail synchronously and never enter into accelerated compositing mode.
Probably much better to set a flag on that bot to disable accelerated
compositing if that's what the bot needs, not try to start gpu and assume
failure is synchronous.


> I think the solution to https://codereview.chromium.org/14238011/ can also
apply
> here. The DoCreateAndInit method should be verifying that the LTH hasn't told
> its client that it's giving up on life before trying to init. The cancel
solves
> that for now (thanks) but we could DCHECK and early-out in DoCreateAndInit if
> the LTH has already done DidRecreateOS(false). WDYT of that?

SG

> This one feels wrong, I guess we need to handle this case. I'm glad we have
some
> test coverage of this. I guess in this case we're going to end up calling
> DidRecreateOutputSurface(true) an extra time for no reason too since we told
LTH
> it lost the context but actually didn't.. doh.
> 
> Cancellable callback is not threadsafe so it's not something we can use to
solve
> this unfortunately.
> 
> So the problem is basically impl side can tell main thread to create output
> surface. By the time it gets to that task, it may have already done it, and
how
> can it tell. We need some kind of extra syncronization between threads. We
could
> use a lock and a variable or some kind to signal, but that's kinda ugly.
> 
> What if the first thing CreateAndInitializeOutputSurface() did was to block
the
> main thread and jump to the impl thread and query if we have an output
surface.
> And then if we do, just early out. That would remove race conditions with the
> main thread doing it in between, and avoid an extra DidLose() and
DidRecreate()
> from going on.
> 

Done

Another idea floating around in my head to avoid this synchronization: Take a
timestamp of when CreateAndInitializeOutputSurface is posted by scheduler, and
when last time output_surface_lost is set to false on main thread, then just
compare them. But it's assuming timestamps have enough resolution, and seems
like a can of worms to maintain.

[danakj, 2013-04-25 15:16:48]

This patch LGTM. One request for a one last test to watch for the race condition
we've solved for CreateAndInitOS() after CompositeAndReadback().

jamesr@ please take a look too!

On 2013/04/25 01:03:35, boliu wrote:
> On 2013/04/24 23:17:13, danakj wrote:
> > 1) The context creation fails. We should not retry and and LTH::Create()
> should
> > return false to match previous expectations and not try create GPU process
> over
> > and over.
> > 
> > 2) The creation works but it gets lost quickly after before we can init the
> > renderer. We should retry in this case.
> > 
> > There used to be some logic in the proxies that held onto an OutputSurface*
> that
> > was created in LTH::Create() in order to make 1) happen. We could retain
that
> by
> > having the proxy only call LTH::CreateOutputSurface when it doesn't have an
> > OutputSurface* already, provided from the LTH::Create() path.
> > 
> > Then, the first time you go to DoCreateAndInitOutputSurface, you could skip
> the
> > create step. The next time around it would be gone and youd have to
> > CreateOutputSurface() again.
> > 
> > What do you think of that?
> 
> Unfortunate but seems necessary at this stage. Makes this patch less lovable.
> And I think Vangelis was suggesting this could improve start up time:
> https://code.google.com/p/chromium/issues/detail?id=230197#c4  Oh well...
> 
> Maybe a better long term solution would be to let embedder set how many times
to
> retry. It can start with 0 and RenderWidget can set it to 5 after first
> OutputSurface created.
> 
> But should definitely fix linux_chromeos first though. It's relying on the
fact
> that we fail synchronously and never enter into accelerated compositing mode.
> Probably much better to set a flag on that bot to disable accelerated
> compositing if that's what the bot needs, not try to start gpu and assume
> failure is synchronous.

I don't think it makes this patch so bad :) I like the idea of splitting that
behaviour change into a separate step. If we can always tell ahead of time when
LTH::Create() is going to fail and avoid calling it altogether, that sounds good
to me..

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host.cc:725: if (!renderer_can_be_initialized_)
guess this should rename to like output_surface_can_be_initialized to be
consistent with these changes

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest.cc (right):

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest.cc:1228: class
LayerTreeHostTestCompositeAndReadbackCleanup : public LayerTreeHostTest {
Could you add a test similar to this to the LTHContextTests, but that does not
EndTest() until DidCommitAndDrawFrame() happens, and verifies that
DidRecreateOS(true) is only happening a single time?

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1134: : LayerTreeHostContextTest()
{
nit: don't need to explcitly name the parent constructor (i learnt this recently
:))

https://codereview.chromium.org/12544032/diff/178001/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/12544032/diff/178001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:51: DCHECK(!layer_tree_host_impl_.get());
nit: don't need the .get() while you're here

[boliu, 2013-04-25 17:25:11]

Two new tests:

LayerTreeHostContextTestCompositeAndReadbackBeforeOutputSurfaceInit to
explicitly test CompositeAndReadback initializes OutputSurface before the
scheduler's posted task runs.

LayerTreeHostTestCannotCreateIfCannotCreateOutputSurface to test if
OutputSurface cannot be created by LTHClient, then fail create LTH. Can't reuse
the LayerTreeTest harness for this because LTT always expects LTH::Create to
succeed, which is a good assumption for all other tests.

James: PTAL

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/178001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1134: : LayerTreeHostContextTest()
{
On 2013/04/25 15:16:49, danakj wrote:
> nit: don't need to explcitly name the parent constructor (i learnt this
recently
> :))

!! Under what conditions is it safe to do this? When the base class has a
default consturctor, and...? Is there a link/discussion I can read?

[danakj, 2013-04-25 17:36:46]

Thanks :) New tests LGTM, I'm glad you did the 2nd one outside of the
LayerTreeTest system.

https://codereview.chromium.org/12544032/diff/183001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/12544032/diff/183001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_unittest_context.cc:1225: EXPECT_EQ(1,
times_output_surface_created_);
Can you move this to AfterTest() in case it does recreate a 2nd time but doesn't
draw again because of the test ending?

[jamesr, 2013-04-25 18:04:53]

lgtm2! Thank you for persisting with this and thank you Dana for all the
reviews.

https://codereview.chromium.org/12544032/diff/190001/cc/trees/proxy.h
File cc/trees/proxy.h (right):

https://codereview.chromium.org/12544032/diff/190001/cc/trees/proxy.h#newcode65
cc/trees/proxy.h:65: //
LayerTreeHost::OnCreateAndInitializeOutputSurfaceAttemptedwith the result.
typo "...Attemptedwith"

[boliu, 2013-04-25 18:11:29]

And thanks for all the guidance and timely reviews.

[commit-bot: I haz the power, 2013-04-25 18:11:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/12544032/142002

[commit-bot: I haz the power, 2013-04-25 20:29:10]

Change committed as 196480

[boliu, 2013-04-25 23:23:43]

Reopening in preparation for reland. Added this to the description:

First commited in r196480. Reverted in r196509 due to exposing 
WebGLInfobarTest that should never have passed on asan. Disable 
them on asan: https://codereview.chromium.org/14499007/

[commit-bot: I haz the power, 2013-04-26 10:09:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/12544032/213002

[commit-bot: I haz the power, 2013-04-26 12:34:57]

Change committed as 196708

[commit-bot: I haz the power, 2013-04-30 23:14:48]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/12544032/213002

[commit-bot: I haz the power, 2013-05-01 00:31:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/12544032/237001

[commit-bot: I haz the power, 2013-05-01 03:13:25]

Change committed as 197550