Call VideoFrameProviderImpl::DidReceiveFrame when background render completes.

Call VideoFrameProviderImpl::DidReceiveFrame when background render completes.

VideoFrameCompositor::OnRendererStateUpdate(true) may run and do a background render after BeginFrame but before the compositor frame is actually drawn. It needs to do DidReceiveFrame so that the layer's update_rect contains the entire video, because UpdateCurrentFrame won't be called and won't modify the update rect until the next BeginFrame.

BUG=515887
Committed: https://crrev.com/0e9c64c2f69e105042297f39a299a897c2d15459
Cr-Commit-Position: refs/heads/master@{#343553}

[jbauman, 2015-08-14 21:24:41]

jbauman@chromium.org changed reviewers:
+ dalecurtis@chromium.org

[hendrikw, 2015-08-14 21:39:20]

I think we can remove had_new_background_frame after this change, I can do this
in a followup.

[DaleCurtis, 2015-08-14 21:50:04]

https://codereview.chromium.org/1299523002/diff/1/media/blink/video_frame_com...
File media/blink/video_frame_compositor.cc (right):

https://codereview.chromium.org/1299523002/diff/1/media/blink/video_frame_com...
media/blink/video_frame_compositor.cc:224: client_->DidReceiveFrame();
Hmm, this means we're calling SetNeedsRedraw() even for occluded/invisible
frames -- which seemed wasteful and thus wasn't done here. Is that concern moot?
It is every 250ms, so I think it might be.

[DaleCurtis, 2015-08-14 21:51:41]

https://codereview.chromium.org/1299523002/diff/1/media/blink/video_frame_com...
File media/blink/video_frame_compositor.cc (right):

https://codereview.chromium.org/1299523002/diff/1/media/blink/video_frame_com...
media/blink/video_frame_compositor.cc:224: client_->DidReceiveFrame();
On 2015/08/14 21:50:03, DaleCurtis wrote:
> Hmm, this means we're calling SetNeedsRedraw() even for occluded/invisible
> frames -- which seemed wasteful and thus wasn't done here. Is that concern
moot?
> It is every 250ms, so I think it might be. 

Actually this can happen as frequently as every 4ms when slaved to WebGL.  See
http://ro.me/ where this might happen.

[jbauman, 2015-08-14 23:05:16]

On 2015/08/14 21:51:41, DaleCurtis wrote:
>
https://codereview.chromium.org/1299523002/diff/1/media/blink/video_frame_com...
> File media/blink/video_frame_compositor.cc (right):
> 
>
https://codereview.chromium.org/1299523002/diff/1/media/blink/video_frame_com...
> media/blink/video_frame_compositor.cc:224: client_->DidReceiveFrame();
> On 2015/08/14 21:50:03, DaleCurtis wrote:
> > Hmm, this means we're calling SetNeedsRedraw() even for occluded/invisible
> > frames -- which seemed wasteful and thus wasn't done here. Is that concern
> moot?
> > It is every 250ms, so I think it might be. 
> 
> Actually this can happen as frequently as every 4ms when slaved to WebGL.  See
> http://ro.me/ where this might happen.

In the 250ms case it probably doesn't matter much. In the 4ms case (in
VideoFrameCompositor::GetCurrentFrameAndUpdateIfStale) client_ will be null so
the SetNeedsRedraw() shouldn't be called

[DaleCurtis, 2015-08-14 23:23:39]

lgtm then, lets see what the bots say.

[jbauman, 2015-08-14 23:36:34]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2015-08-14 23:37:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1299523002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1299523002/1

[commit-bot: I haz the power, 2015-08-15 02:58:15]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-08-15 02:59:12]

Patchset 1 (id:??) landed as
https://crrev.com/0e9c64c2f69e105042297f39a299a897c2d15459
Cr-Commit-Position: refs/heads/master@{#343553}