Remove the code that prevents task blocking if not expecting frames

Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

Removing this condition is safe because:
a. We are now using task blocking in more limited cases
b. For the usual compositor scrolling case we increased the blocking
threshold to 50ms

BUG=574343
Committed: https://crrev.com/fad210f8d90fcecd334a0383e6194f70f120f91f
Cr-Commit-Position: refs/heads/master@{#371521}

[alex clarke (OOO till 29th), 2016-01-26 14:56:39]

Description was changed from

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockig if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
should be blokcing tasks that take longer than 50ms even if we're not
expecting frames because touch starts can and will get delayed.

BUG=574343
==========

to

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

BUG=574343
==========

[alex clarke (OOO till 29th), 2016-01-26 14:56:45]

The CQ bit was checked by alexclarke@chromium.org to run a CQ dry run

[alex clarke (OOO till 29th), 2016-01-26 14:56:57]

alexclarke@chromium.org changed reviewers:
+ skyostil@chromium.org

[commit-bot: I haz the power, 2016-01-26 14:57:05]

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

[alex clarke (OOO till 29th), 2016-01-26 14:57:06]

PTAL

[Sami, 2016-01-26 15:11:35]

lgtm. Could you add a sentence to the changelog along the lines that removing
this condition is safe because we are now using task blocking in more limited
cases?

[alex clarke (OOO till 29th), 2016-01-26 15:13:48]

Description was changed from

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

BUG=574343
==========

to

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

Removing this condition is safe because:
a. We are now using task blocking in more limited cases
b. For the usual compositor scrolling case we increased the blocking 
threshold to 50ms

BUG=574343
==========

[alex clarke (OOO till 29th), 2016-01-26 15:13:58]

On 2016/01/26 15:11:35, Sami wrote:
> lgtm. Could you add a sentence to the changelog along the lines that removing
> this condition is safe because we are now using task blocking in more limited
> cases?

Done

[alex clarke (OOO till 29th), 2016-01-26 15:14:02]

The CQ bit was unchecked by alexclarke@chromium.org

[alex clarke (OOO till 29th), 2016-01-26 15:14:11]

The CQ bit was checked by alexclarke@chromium.org

[commit-bot: I haz the power, 2016-01-26 15:14:22]

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

[commit-bot: I haz the power, 2016-01-26 16:14:11]

Description was changed from

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

Removing this condition is safe because:
a. We are now using task blocking in more limited cases
b. For the usual compositor scrolling case we increased the blocking 
threshold to 50ms

BUG=574343
==========

to

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

Removing this condition is safe because:
a. We are now using task blocking in more limited cases
b. For the usual compositor scrolling case we increased the blocking 
threshold to 50ms

BUG=574343
==========

[commit-bot: I haz the power, 2016-01-26 16:14:12]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-26 16:15:31]

Description was changed from

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

Removing this condition is safe because:
a. We are now using task blocking in more limited cases
b. For the usual compositor scrolling case we increased the blocking 
threshold to 50ms

BUG=574343
==========

to

==========
Remove the code that prevents task blocking if not expecting frames

In abstract preventing task blockimg if not expecting frames sounds like
a good idea.  In practice it caused a large perf regression since we
probably should be blocking tasks that take longer than 50ms even if we're
not expecting frames because touch starts can and will get delayed.

Removing this condition is safe because:
a. We are now using task blocking in more limited cases
b. For the usual compositor scrolling case we increased the blocking
threshold to 50ms

BUG=574343

Committed: https://crrev.com/fad210f8d90fcecd334a0383e6194f70f120f91f
Cr-Commit-Position: refs/heads/master@{#371521}
==========

[commit-bot: I haz the power, 2016-01-26 16:15:32]

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