cc: Update Main RendererCapabilities on DeferredInitialize

cc/layers/texture_layer.cc

 // Copyright 2010 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/layers/texture_layer.h"
 
 #include "base/bind.h"
 #include "base/callback_helpers.h"
 #include "base/location.h"
 #include "base/synchronization/lock.h"
@@ skipping 258 matching lines @@
       release_callback = holder->GetCallbackForImplThread();
     }
     texture_layer->SetTextureMailbox(texture_mailbox, release_callback.Pass());
     needs_set_mailbox_ = false;
   } else {
     texture_layer->SetTextureId(texture_id_);
     content_committed_ = DrawsContent();
   }
 }
 
+void TextureLayer::OnOutputSurfaceCreated() {
+  if (uses_mailbox_) {

[danakj, 2014/02/11 19:58:59]

If we release the mailbox here, we should be calling SetNeedsCommit()? How does
this relate to the content on the impl thread? We can't just go using that
content now right? I'm not sure how we'd try prevent it tho..

[boliu, 2014/02/11 21:44:07]

That's already handled on the impl side (DeferredInitialize and ReleaseGL
already calls SetNeedsCommit). Don't need and probably don't want main layers to
set that racily too.
s/content/context/ ?

So the context used by accelerated canvas is *not* lost or destroyed when
ReleaseGL happens. There are a few cases:

If mailbox has not been committed to impl side, then we just release it back to
client here.

If the mailbox has already been committed to impl side, then impl layer will
have already released it by this point, so this reset will probably do nothing.

The edge case is the impl release races with an update here, so it's possible
impl side released mailbox n, and we are already holding mailbox n+1. And we'll
release n+1 also.

[boliu, 2014/02/12 01:48:57]

Actually I'm not clear what your concern is about the impl context here.

For accelerated canvas in webview case, the canvas context will still be alive
even if webview goes back to software mode.

And I think in general, we shouldn't assume compositor impl context loss also
means main thread context lost? I don't really know how context loss happens on
desktop though :/

Also this should be called only after a new context/OS has been recreated as the
name implies.

[danakj, 2014/02/12 15:40:01]

I did mean content, the impl side texture. But then as you said, the impl side
is already released first when we get here. Can we DCHECK here that this is the
last reference left on the mailbox holder? The release post-task should have
been run first right?

[boliu, 2014/02/12 17:45:27]

Good suggestion. Caught an edge case that I haven't thought of.

If DeferredInitialize or ReleaseGL comes after
ThreadProxy::StartCommitOnImplThread but before
ThreadProxy::ScheduledActionCommit, then the commit will go through with stale
renderer caps, and this check will fail.

I think can solve this by moving the staleness check to
ThreadProxy::UpdateRendererCapabilitiesOnImplThread. Coding it up now and seeing
if it works.

+    holder_ref_.reset();

[boliu, 2014/02/07 04:29:55]

So for mailboxes the contract is maintained implicitly in the client, that if
the previous mailbox is returned, then the layer will need another one in the
next PrepareTextureMailbox. Can easily follow up to make that explicit by
passing an arg in PrepareTextureMailbox.

I'm not sure what the current contract is when uses_mailbox_ is false though.
Webview doesn't care at the moment. I think the explicit arg will work as well?

[danakj, 2014/02/11 19:58:59]

It'd be nice to just mark the layer as "bad" until it gets a new resource, and
prevent drawing until no layers are "bad". That'd let us avoid drawing black
layers without forcing the client to block in PrepareTextureMailbox.

For non-mailbox, the client watches its context and gets told when the context
is lost. Consumers of it are aura reflectors and android ui, neither of which
webview cares about. We should just delete the code path rather than adding
complexity to it.

[boliu, 2014/02/11 21:44:07]

Could I do this in a follow up? :p

Or do you think I'm breaking something with this change already?
And more follow up...

[boliu, 2014/02/12 01:48:57]

This should just work right now?

Without a valid mailbox, and if PrepareTextureMailbox/PrepareTexture returning
false, TextureLayer::Update will return false as well. So client doesn't need to
block, just need to call SetNeedsUpdate when it's ready.

And in TextureLayerImpl::WillDraw, if layer doesn't have a valid
Mailbox/Texture, it will return false, and AppendQuads will be skipped, so will
not draw black box.

[danakj, 2014/02/12 15:40:01]

Oh, we'll draw a frame without the layer there, which is still visually weird
though. I didn't mean that you need to do that in this CL, but we're setting
ourselves up for it, so it'd be nice to do.

+  }
+}
+
 Region TextureLayer::VisibleContentOpaqueRegion() const {
   if (contents_opaque())
     return visible_content_rect();
 
   if (blend_background_color_ && (SkColorGetA(background_color()) == 0xFF))
     return visible_content_rect();
 
   return Region();
 }
 
@@ skipping 62 matching lines @@
 
 void TextureLayer::TextureMailboxHolder::ReturnAndReleaseOnImplThread(
     uint32 sync_point,
     bool is_lost) {
   Return(sync_point, is_lost);
   message_loop_->PostTask(
       FROM_HERE, base::Bind(&TextureMailboxHolder::InternalRelease, this));
 }
 
 }  // namespace cc