Add occlusion support to WebContentsImpl and RenderWidgetHostView

Add occlusion support to WebContentsImpl and RenderWidgetHostView

Add a WasOccluded and WasUnOccluded methods to WebContentsImpl, and
call them on Mac when window occlusion changes. Filter these methods
based on whether or not the WebContentsImpl is being captured, and send
them to the RenderWidgetHostView. Add tests to make sure that this and
the effect of capture on visibility don't regress.

Implement WasOccluded and WasUnOccluded only on Mac, where the calls
have the effect of telling the RenderWidgetHostImpl that it is hidden
(to drop the power consumption) and freezing but not removing the
CALayer used by the ui::Compositor (so that content is present when
the window is revealed).

Move the call to ui::Compositor::SetRootLayer to the browser compositor
suspend function to ensure no new frames are drawn after suspend (this
may have the effect of skipping the last-visible frame, but it will be
re-drawn on reveal anyway).

BUG=310374
Committed: https://crrev.com/8807c38fee5e34d7811d96191989eed8a4653e50
Cr-Commit-Position: refs/heads/master@{#311989}

[ccameron, 2015-01-16 19:01:09]

ccameron@chromium.org changed reviewers:
+ avi@chromium.org, miu@chromium.org

[ccameron, 2015-01-16 19:01:11]

This turned out to be fairly simple (& is unrelated to the design doc circulated
-- it turns out my ideas in the doc are impossible).

I would like, in the future, to be able to detach the DelegatedFrameHost from
the RWHV's ui::Compositor and re-attach it to a "for capture only"
ui::Compositor, so that we can manage the RWHV's visibility correctly even when
we are capturing (and not defer the WasHidden calls). But, that's a big yak to
shave & possibly never worth it. Maybe if/when we get Android on to
DelegatedFrameHost et al, it will be an option.

https://codereview.chromium.org/853883007/diff/40001/content/browser/web_cont...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/853883007/diff/40001/content/browser/web_cont...
content/browser/web_contents/web_contents_impl.cc:930: WasUnOccluded();
I think there's a bug here where we will get into an inconsistent state if we
try to capture while hidden (perhaps that isn't possible?). I'm going to clean
up the WasHidden/WasShown code in a future patch (future b/c it will have
effects on non-Mac platforms).

[Avi (use Gerrit), 2015-01-16 20:15:13]

LGTM for cocoa stuff, but miu needs to look at the graphics side of things.

https://codereview.chromium.org/853883007/diff/40001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/853883007/diff/40001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:622:
browser_compositor_->compositor()->SetRootLayer(NULL);
nullptr?

https://codereview.chromium.org/853883007/diff/40001/content/public/browser/r...
File content/public/browser/render_widget_host_view.h (right):

https://codereview.chromium.org/853883007/diff/40001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:96: // Indicates if the view is
currently occluded and the view may be suspended.
You might want to give an "e.g." for occlusion here, as that word might not be
in everyone vocabulary (and isn't even in my spellcheck).

https://codereview.chromium.org/853883007/diff/40001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:98: // un-occluded. These calls
do not necessarily made in pairs.
"do not necessarily made" is weird grammar; clean that up. But this is a huge
point, that these aren't nesting calls, so make that clear.

[ccameron, 2015-01-16 21:43:40]

Thanks -- updated.

https://codereview.chromium.org/853883007/diff/40001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/853883007/diff/40001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:622:
browser_compositor_->compositor()->SetRootLayer(NULL);
On 2015/01/16 20:15:13, Avi wrote:
> nullptr?

Done.

https://codereview.chromium.org/853883007/diff/40001/content/public/browser/r...
File content/public/browser/render_widget_host_view.h (right):

https://codereview.chromium.org/853883007/diff/40001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:96: // Indicates if the view is
currently occluded and the view may be suspended.
On 2015/01/16 20:15:13, Avi wrote:
> You might want to give an "e.g." for occlusion here, as that word might not be
> in everyone vocabulary (and isn't even in my spellcheck).

Done.

https://codereview.chromium.org/853883007/diff/40001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:98: // un-occluded. These calls
do not necessarily made in pairs.
On 2015/01/16 20:15:13, Avi wrote:
> "do not necessarily made" is weird grammar; clean that up. But this is a huge
> point, that these aren't nesting calls, so make that clear.

Fixed. Also expanded on the points of being re-set.

[Avi (use Gerrit), 2015-01-16 21:47:11]

https://codereview.chromium.org/853883007/diff/60001/content/public/browser/r...
File content/public/browser/render_widget_host_view.h (right):

https://codereview.chromium.org/853883007/diff/60001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:97: // covered up by other
windows on Mac), and as a result the view's renderer
Occlusion is a phenomenon that happens on all platforms, not just on the Mac.
Pull the "on Mac" part out of the parentheses. You can say that these functions
are called only on the Mac for now.

[ccameron, 2015-01-16 21:54:07]

Updated.

https://codereview.chromium.org/853883007/diff/60001/content/public/browser/r...
File content/public/browser/render_widget_host_view.h (right):

https://codereview.chromium.org/853883007/diff/60001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:97: // covered up by other
windows on Mac), and as a result the view's renderer
On 2015/01/16 21:47:11, Avi wrote:
> Occlusion is a phenomenon that happens on all platforms, not just on the Mac.
> Pull the "on Mac" part out of the parentheses. You can say that these
functions
> are called only on the Mac for now.

Updated (I left a sentence at the end saying it's just for Mac, but I'm hoping
to throw support for this into ash as well).

[Avi (use Gerrit), 2015-01-16 21:58:21]

Yep, that looks nice. LGTM still, and it's good to hear that we're going to get
it on other platforms too.

[miu, 2015-01-16 22:24:51]

lgtm

Thanks for also adding the unit testing around the tab capture case.  Peace of
mind...  :)

https://codereview.chromium.org/853883007/diff/80001/content/public/browser/r...
File content/public/browser/render_widget_host_view.h (right):

https://codereview.chromium.org/853883007/diff/80001/content/public/browser/r...
content/public/browser/render_widget_host_view.h:100: // that). These calls are
not necessarily made in pairs. This is currently
nit: Maybe don't mention in the public API that "This is currently only called
on Mac."  IMO, what you have in this change is a good API when/if support on
other platforms can be added.

[ccameron, 2015-01-16 22:54:00]

Thanks all. Pulled the Mac comment.

[ccameron, 2015-01-16 22:54:04]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2015-01-16 22:55:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/853883007/100001

[commit-bot: I haz the power, 2015-01-17 00:29:49]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-01-17 00:30:35]

Patchset 6 (id:??) landed as
https://crrev.com/8807c38fee5e34d7811d96191989eed8a4653e50
Cr-Commit-Position: refs/heads/master@{#311989}