Simplify CanvasAsyncBlobCreator by removing ContextObserver and related tests

Simplify CanvasAsyncBlobCreator by removing ContextObserver and related tests

After we confirm to use idle-tasks implementation in toBlob, the cancellation
mechanism for async thread implementation is no longer useful. First, compositor
thread is definitely alive when users open Chrome browser; so the alternative
code path for PNG image encoding when compositor thread is disabled would be
unreachable in real-world situations; as a result, PNG image encoding happens
in idle tasks only. Second, JPEG and WEBP image formats do not have progressive
encoding at this moment and thus cancellation mechanism is not useful to them
either; once their progressive encoding implementations are completed, they
would be moved over to idle-tasks implementation too.

This patch removes ContextObserver and CanvasAsyncBlobCreatorTest; it also moves
all layout tests that use toBlob on PNG image formats to virtual/threaded as
idle tasks require compositor thread to be alive. There is no need to perform
tests on toBlob (png) in scenarios when compositor thread is not available.

BUG=581574
Committed: https://crrev.com/d3991457ab5fcb905f2a8a07657e26b16b2974fa
Cr-Commit-Position: refs/heads/master@{#373068}

[xlai (Olivia), 2016-02-02 16:42:06]

xlai@chromium.org changed reviewers:
+ junov@chromium.org

[xlai (Olivia), 2016-02-02 16:42:07]

junov@: One thing I am considering is that once we want to handle the situation
when idle tasks are postponed indefinitely and we have to switch over to
threaded implementation as an alternative route, will this context observer
still be relevant in that situation? But I highly suspect that it's not worthy
making the solution so complex just to handle that highly unlikely situation
(i.e., main thread too busy postponing idle tasks indefinitely but when tasks
are handed over to async thread pool the main thread js execution context is
suddenly torn down).

[Justin Novosad, 2016-02-02 18:35:49]

The alternative route might be an immediate decode on the main thread, which
would not need a cancellation mechanism.  The alternative could also be a
background task. It may be a bit early to rip out all this code.  Perhaps we
should wait to see what the final strategy is going to be?

[xlai (Olivia), 2016-02-02 20:57:36]

On 2016/02/02 18:35:49, Justin Novosad wrote:
> The alternative route might be an immediate decode on the main thread, which
> would not need a cancellation mechanism.  The alternative could also be a
> background task. It may be a bit early to rip out all this code.  Perhaps we
> should wait to see what the final strategy is going to be?

At this moment, the context observer is only used by webp/jpeg encoders but it's
not very useful as both are non-progressive. In the future, it's going to
become dead code when webp/jpeg encoders are moved over to idle tasks.

We can adjust it a bit but it'll be a complex solution that handles a quite 
unlikely situation (idle tasks getting postponed indefinitely + after passing to
async thread then main thread execution context gets torn down). However, even 
this situation can be avoided by a simpler, different solution--that is, posting

the encoding task to main thread if the idle tasks are postponed for too long
due
to the main thread being too busy.

[Justin Novosad, 2016-02-02 21:02:00]

lgtm

[xlai (Olivia), 2016-02-02 21:37:15]

The CQ bit was checked by xlai@chromium.org

[commit-bot: I haz the power, 2016-02-02 21:43:24]

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

[commit-bot: I haz the power, 2016-02-02 23:19:30]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-02-02 23:21:10]

Description was changed from

==========
Simplify CanvasAsyncBlobCreator by removing ContextObserver and related tests

After we confirm to use idle-tasks implementation in toBlob, the cancellation
mechanism for async thread implementation is no longer useful. First, compositor
thread is definitely alive when users open Chrome browser; so the alternative
code path for PNG image encoding when compositor thread is disabled would be
unreachable in real-world situations; as a result, PNG image encoding happens
in idle tasks only. Second, JPEG and WEBP image formats do not have progressive
encoding at this moment and thus cancellation mechanism is not useful to them
either; once their progressive encoding implementations are completed, they
would be moved over to idle-tasks implementation too.

This patch removes ContextObserver and CanvasAsyncBlobCreatorTest; it also moves
all layout tests that use toBlob on PNG image formats to virtual/threaded as
idle tasks require compositor thread to be alive. There is no need to perform
tests on toBlob (png) in scenarios when compositor thread is not available.


BUG=581574
==========

to

==========
Simplify CanvasAsyncBlobCreator by removing ContextObserver and related tests

After we confirm to use idle-tasks implementation in toBlob, the cancellation
mechanism for async thread implementation is no longer useful. First, compositor
thread is definitely alive when users open Chrome browser; so the alternative
code path for PNG image encoding when compositor thread is disabled would be
unreachable in real-world situations; as a result, PNG image encoding happens
in idle tasks only. Second, JPEG and WEBP image formats do not have progressive
encoding at this moment and thus cancellation mechanism is not useful to them
either; once their progressive encoding implementations are completed, they
would be moved over to idle-tasks implementation too.

This patch removes ContextObserver and CanvasAsyncBlobCreatorTest; it also moves
all layout tests that use toBlob on PNG image formats to virtual/threaded as
idle tasks require compositor thread to be alive. There is no need to perform
tests on toBlob (png) in scenarios when compositor thread is not available.

BUG=581574

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

[commit-bot: I haz the power, 2016-02-02 23:21:11]

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

[Stephen Chennney, 2016-02-03 16:17:30]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.chromium.org/1660993002/ by schenney@chromium.org.

The reason for reverting is: This patch appears to be causing Document leaks.
See, for example:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Leak/b....