Don't defer commit until draw if not drawing soon

Don't defer commit until draw if not drawing soon

This will help avoid wedging the main thread for cases where
we might not receive BeginFrames.

It should also help release the main thread sooner if we
aren't going to draw the active tree anytime soon.

BUG=479671, 477082

[brianderson, 2015-04-22 18:40:48]

brianderson@chromium.org changed reviewers:
+ sunnyps@chromium.org

[brianderson, 2015-04-22 18:40:48]

Need to add unit tests still and might make active_tree_first_draw_is_imminent a
function, but ptal.

[brianderson, 2015-04-22 18:51:51]

Sadly, this causes wedging when I resize. Will need to iron those out if we want
to go this route.

[boliu, 2015-04-22 18:54:32]

On 2015/04/22 18:51:51, brianderson wrote:
> Sadly, this causes wedging when I resize. Will need to iron those out if we
want
> to go this route.

Is there anything wrong with what sunny proposed in
https://code.google.com/p/chromium/issues/detail?id=479671#c12 ? Conceptually,
webview's BeginFrame should correspond to chrome's draw+swaps in terms of
pipelining things are concerned, just like before

Will need to merge this to m43, so whatever is small/safe is good :)

[brianderson, 2015-04-24 03:45:57]

Actually, I can't reproduce the resize hang anymore after syncing to ToT. Not
sure what happened. =/

I'm going to write unit tests for this and see if I can land it. I think it will
fix the BeginMainFrame hangs we've been seeing on Windows since NPAPI will
theoretically have a similar problem:
https://code.google.com/p/chromium/issues/detail?id=477082

I think the Browser can't send us a SwapAck and because it's blocked on the main
thread which is blocked on active_tree_needs_first_draw_.

Sunny's patch that clears active_tree_needs_first_draw_ on invalidation won't
help Windows.

[brianderson, 2015-05-13 23:29:11]

Moving this to https://codereview.chromium.org/1139613003