aw: Ensure fallback tick unsets |block_invalidates_|

aw: Ensure fallback tick unsets |block_invalidates_|

Currently, if |compositor_needs_continuous_invalidate_| is unset before
PostFallbackTick or FallbackTickFired, then the fallback ticks are
cancelled, but we never unset |block_invalidates_|, which will block
invalidates indefinitely.

Fix is simply always unset |block_invalidates_| even if we skip
the fallback tick.

BUG=408779
Committed: https://crrev.com/d3ba7205b5a0c9154b91357c8795e772833fa798
Cr-Commit-Position: refs/heads/master@{#292511}

[boliu, 2014-08-28 21:48:18]

Patchset #2 (id:20001) has been deleted

[boliu, 2014-08-28 21:49:04]

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

[boliu, 2014-08-28 21:49:04]

I think the name "DidComposite" doesn't make sense anymore, but I'm trying to
keep this small for merges.

[hush (inactive), 2014-08-28 22:09:29]

Hi Bo,
Thanks for the fix!
So the issue is compositor_needs_continuous_invalidate_ gets set to false before
the fallback tick actually happen and we end up not calling
"ForceFakeCompositeSW" right?

btw,
Yesterday, I tried to fix this in hackish way by always calling
ForceFakeCompositeSW() in FallbackTickFired() without checking the conditions.
I'm surprised that fix didn't work out for me....

[hush (inactive), 2014-08-28 22:12:24]

On 2014/08/28 22:09:29, hush wrote:
> Hi Bo,
> Thanks for the fix!
> So the issue is compositor_needs_continuous_invalidate_ gets set to false
before
> the fallback tick actually happen and we end up not calling
> "ForceFakeCompositeSW" right?
> 
> btw,
> Yesterday, I tried to fix this in hackish way by always calling
> ForceFakeCompositeSW() in FallbackTickFired() without checking the conditions.
> I'm surprised that fix didn't work out for me....

Looking at your fix I realized PostFallbackTickFired is the other piece I
missed.

Thanks!

let's clean up "DidComposite" later.
lgtm

[boliu, 2014-08-28 22:12:37]

On 2014/08/28 22:09:29, hush wrote:
> Hi Bo,
> Thanks for the fix!
> So the issue is compositor_needs_continuous_invalidate_ gets set to false
before
> the fallback tick actually happen and we end up not calling
> "ForceFakeCompositeSW" right?

Yes

> 
> btw,
> Yesterday, I tried to fix this in hackish way by always calling
> ForceFakeCompositeSW() in FallbackTickFired() without checking the conditions.
> I'm surprised that fix didn't work out for me....

You missed PostFallbackTick. FallbackTickFired could be skipped if
compositor_needs_continuous_invalidate_ is set to false before PostFallbackTick
runs. If you put ForceFakeCompositeSW into PostFallbackTick, then it would have
worked I think.

[boliu, 2014-08-28 22:13:20]

The CQ bit was checked by boliu@chromium.org

[commit-bot: I haz the power, 2014-08-28 22:14:58]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/boliu@chromium.org/512403002/1

[commit-bot: I haz the power, 2014-08-29 00:00:44]

Committed patchset #1 (id:1) as b95da1a5ddb8f290395dad31f823f24bbc4a2778

[commit-bot: I haz the power, 2014-09-10 03:04:00]

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