aw: Ensure invalidation when pipeline is stalled

aw: Ensure invalidation when pipeline is stalled

* If CommitFrame is skipped to to stall, ensure we invalidate.
* Make sure force_invalidate does not get cancelled by a
  pending fallback tick.
* Allow hardware initialization even when visible rect is
  empty, so fallback tick is always in the right mode.
* Fix visible rect empty checks.

BUG=425372
Committed: https://crrev.com/6b96a049428fceb4af34a5ea92b106ae208ea75b
Cr-Commit-Position: refs/heads/master@{#300566}

[boliu, 2014-10-17 15:45:53]

boliu@chromium.org changed reviewers:
+ hush@chromium.org

[boliu, 2014-10-17 15:45:54]

We need some form of this in m39...

[boliu, 2014-10-20 17:36:09]

I want to pull in the proper fix for b/18009042 into this.

https://codereview.chromium.org/654403006/diff/20001/android_webview/browser/...
File android_webview/browser/shared_renderer_state.cc (right):

https://codereview.chromium.org/654403006/diff/20001/android_webview/browser/...
android_webview/browser/shared_renderer_state.cc:198:
client_on_ui_->PostInvalidate();
This is horrible. Any brilliant ideas how to make this saner?

[boliu, 2014-10-21 00:32:38]

Ok, has a real description and a bug now.

[hush (inactive), 2014-10-21 01:47:21]

https://codereview.chromium.org/654403006/diff/100001/android_webview/browser...
File android_webview/browser/browser_view_renderer.cc (right):

https://codereview.chromium.org/654403006/diff/100001/android_webview/browser...
android_webview/browser/browser_view_renderer.cc:319: // Need to keep
invalidating until pipelien is no longer stalled.
typo: pipeline

also, can you put this function together with "SkippedCompositeInDraw"? They are
very similiar.
Maybe rename them to the same pattern as well, like "DidSkipCommitFrame" and
"DidSkipCompositeInDraw"

https://codereview.chromium.org/654403006/diff/100001/android_webview/browser...
android_webview/browser/browser_view_renderer.cc:320:
EnsureContinuousInvalidation(true, false);
Just to make sure I am understanding this correctly:
EnsureContinuousInvalidation wouldn't call PostInvalidate if block_invalidates
is true, which means a fallback tick is scheduled but not fired yet. This
fallback tick must be a real, hardware-accelerated fallback tick, because a fake
software fallback tick may not work. Since this function is called from the
parent compositor, we're guaranteed that at this point, the scheduled fallback
tick is the hardware accelerated one?

Actually, is it possible that the scheduled fallback tick is still a software
one at this point?

[boliu, 2014-10-21 02:03:59]

Fixed not rescheduling fallback tick as discussed offline.

https://codereview.chromium.org/654403006/diff/100001/android_webview/browser...
File android_webview/browser/browser_view_renderer.cc (right):

https://codereview.chromium.org/654403006/diff/100001/android_webview/browser...
android_webview/browser/browser_view_renderer.cc:320:
EnsureContinuousInvalidation(true, false);
On 2014/10/21 01:47:21, hush wrote:
> Just to make sure I am understanding this correctly:
> EnsureContinuousInvalidation wouldn't call PostInvalidate if block_invalidates
> is true, which means a fallback tick is scheduled but not fired yet. 

Yes

> This
> fallback tick must be a real, hardware-accelerated fallback tick, because a
fake
> software fallback tick may not work.

Mode shouldn't matter imo.

> Since this function is called from the
> parent compositor, we're guaranteed that at this point, the scheduled fallback
> tick is the hardware accelerated one?
> 
> Actually, is it possible that the scheduled fallback tick is still a software
> one at this point?

Yeah if a trim comes in.

[hush (inactive), 2014-10-21 20:38:11]

lgtm

https://codereview.chromium.org/654403006/diff/120001/android_webview/browser...
File android_webview/browser/browser_view_renderer.cc (right):

https://codereview.chromium.org/654403006/diff/120001/android_webview/browser...
android_webview/browser/browser_view_renderer.cc:296:
EnsureContinuousInvalidation(true, needs_force_invalidate);
Just a comment for the record. We discussed this in person.
This line will ensure a real invalidation will be called eventually, even though
at this moment a pending fallback tick (regardless of whether it is software or
hardware mode) is blocking the invalidates. That is because if there is a
pending fallback tick,  when the fallback tick is fired, block_invalidates_ will
be false and EnsureContinuousInvalidation will be called again. Then WebView
will post a real invalidate.

[boliu, 2014-10-21 21:23:55]

The CQ bit was checked by boliu@chromium.org

[commit-bot: I haz the power, 2014-10-21 21:24:55]

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

[commit-bot: I haz the power, 2014-10-21 23:24:17]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2014-10-21 23:26:04]

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