Change GraphicsContext::createCompatibleBuffer to return something non-null

Change GraphicsContext::createCompatibleBuffer to return something non-null

The former implementation asked the current SkCanvas, in all cases now a
SkPictureRecord, for a new SkSurface. The SkPictureRecord always returned null for
the SkSurface. Now we just return a new bitmap surface regardless.

There are two pieces of code that depend on this: cross-fade and SVG
buffered-rendering (which apparently is going away, see crbug.com/395766).
For some reason the cross fade code worked anyway, maybe due to some
fallback path, but the SVG caching didn't.

Note we don't want any of this rasterization during recording. But for
now it stays.

R=fmalita@chromium.org,reed@google.com
BUG=394765, 394768
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=178448

[Stephen Chennney, 2014-07-17 19:12:11]

Found this while looking as Slimming Paint changes. I know it's suboptimal, but
right now I think we just do the dumb thing. I'm just wondering if there's a
less dumb thing.

[reed1, 2014-07-17 20:36:58]

Can we rename the function to not say compatible, but raster?

[Stephen Chennney, 2014-07-17 20:44:01]

On 2014/07/17 20:36:58, reed1 wrote:
> Can we rename the function to not say compatible, but raster?

Yeah, good idea. I'll get to it tomorrow.

[f(malita), 2014-07-17 20:44:38]

On 2014/07/17 20:44:01, Stephen Chenney wrote:
> On 2014/07/17 20:36:58, reed1 wrote:
> > Can we rename the function to not say compatible, but raster?
> 
> Yeah, good idea. I'll get to it tomorrow.

LGTM with rename.

[Stephen Chennney, 2014-07-18 14:17:26]

The CQ bit was checked by schenney@chromium.org

[commit-bot: I haz the power, 2014-07-18 14:18:36]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/schenney@chromium.org/399213002/20001

[commit-bot: I haz the power, 2014-07-18 15:24:32]

Change committed as 178448