Avoid making the shared main thread context if we won't use it.

Avoid making the shared main thread context if we won't use it.

When deciding if HTMLCanvasElement should be accelerated we changed
the code to get the shared main thread context before making the
decision because it's part of the decision. However, for most of the
things we decide on (such as are-we-using-display-list-canvas) we
don't care about the context. We only care once we decide we do want
to use it, then verify it's not using swiftshader.

So, defer getting/creating the shared main thread context until we
know we want to accelerate, then just fail to accelerate if swiftshader.

To make this logic more clear, I split the createImageBufferSurface()
method into createAcceleratedImageBufferSurface() and
createSoftwareImageBufferSurface() which is used if the former
fails/returns null. There is less nesting now so hopefully that's nice.

With this the memory.blink_memory_mobile's TheVerge case goes from
6422Kb of gpu memory back down to 4324Kb.

TBR=junov@chromium.org, kbr@chromium.org
BUG=640811, 606056
Review-Url: https://codereview.chromium.org/2280723003
Cr-Commit-Position: refs/heads/master@{#414806}
(cherry picked from commit 03fe53dc4730038b5d13613fcbad10fc9a204c54)

Committed: https://chromium.googlesource.com/chromium/src/+/29e2540ac9bf025bb174d55543b7596e550920cd

[danakj, 2016-09-01 21:18:14]

Description was changed from

==========
Avoid making the shared main thread context if we won't use it.

When deciding if HTMLCanvasElement should be accelerated we changed
the code to get the shared main thread context before making the
decision because it's part of the decision. However, for most of the
things we decide on (such as are-we-using-display-list-canvas) we
don't care about the context. We only care once we decide we do want
to use it, then verify it's not using swiftshader.

So, defer getting/creating the shared main thread context until we
know we want to accelerate, then just fail to accelerate if swiftshader.

To make this logic more clear, I split the createImageBufferSurface()
method into createAcceleratedImageBufferSurface() and
createSoftwareImageBufferSurface() which is used if the former
fails/returns null. There is less nesting now so hopefully that's nice.

With this the memory.blink_memory_mobile's TheVerge case goes from
6422Kb of gpu memory back down to 4324Kb.

TBR=junov@chromium.org, kbr@chromium.org
BUG=640811,606056

Review-Url: https://codereview.chromium.org/2280723003
Cr-Commit-Position: refs/heads/master@{#414806}
(cherry picked from commit 03fe53dc4730038b5d13613fcbad10fc9a204c54)
==========

to

==========
Avoid making the shared main thread context if we won't use it.

When deciding if HTMLCanvasElement should be accelerated we changed
the code to get the shared main thread context before making the
decision because it's part of the decision. However, for most of the
things we decide on (such as are-we-using-display-list-canvas) we
don't care about the context. We only care once we decide we do want
to use it, then verify it's not using swiftshader.

So, defer getting/creating the shared main thread context until we
know we want to accelerate, then just fail to accelerate if swiftshader.

To make this logic more clear, I split the createImageBufferSurface()
method into createAcceleratedImageBufferSurface() and
createSoftwareImageBufferSurface() which is used if the former
fails/returns null. There is less nesting now so hopefully that's nice.

With this the memory.blink_memory_mobile's TheVerge case goes from
6422Kb of gpu memory back down to 4324Kb.

TBR=junov@chromium.org, kbr@chromium.org
BUG=640811,606056

Review-Url: https://codereview.chromium.org/2280723003
Cr-Commit-Position: refs/heads/master@{#414806}
(cherry picked from commit 03fe53dc4730038b5d13613fcbad10fc9a204c54)

Committed:
https://chromium.googlesource.com/chromium/src/+/29e2540ac9bf025bb174d55543b7...
==========

[danakj, 2016-09-01 21:18:16]

Committed patchset #1 (id:1) manually as
29e2540ac9bf025bb174d55543b7596e550920cd.