Add NULL check to createPlatformTexture

[bsalomon, 2012-01-03 19:41:46]

This is causing crashes in the canary. I don't understand yet why the texture is
NULL, though.

[TomH, 2012-01-03 19:49:23]

Digging deeper:

It looks like the callers are all several layers away in Chromium code. Are we
confident they can handle NULLs? (A quick inspection spots
FrameBufferSkPictureCanvasLayerTextureUpdater, which passes the target to the
SkGpuDevice constructor, which doesn't look NULL-tolerant.)

[bsalomon, 2012-01-03 20:15:35]

On 2012/01/03 19:49:23, TomH wrote:
> Digging deeper:
> 
> It looks like the callers are all several layers away in Chromium code. Are we
> confident they can handle NULLs? (A quick inspection spots
> FrameBufferSkPictureCanvasLayerTextureUpdater, which passes the target to the
> SkGpuDevice constructor, which doesn't look NULL-tolerant.)

Yeah, I saw that too. To me that is a bug in the WK code. It shouldn't ever
construct a gpu device with a NULL texture/rt.

I still think we want this change, though.

[TomH, 2012-01-03 20:18:11]

Yes, this change is good. LGTM.

But we (by which I suppose I mean you) should be getting somebody to fix the
WebKit use case, or doing it (y)ourselves, right? I've already got my change
blocking rolls, I'm hesitant to sign off on another change that would also be
blocking rolls... :(

[bsalomon, 2012-01-03 21:10:39]

On 2012/01/03 20:18:11, TomH wrote:
> Yes, this change is good. LGTM.
> 
> But we (by which I suppose I mean you) should be getting somebody to fix the
> WebKit use case, or doing it (y)ourselves, right? I've already got my change
> blocking rolls, I'm hesitant to sign off on another change that would also be
> blocking rolls... :(

This code is only invoked in accel drawing so it shouldn't affect rolling skia.
It will defer a crash in that path. Making the caller NULL tolerant (and
figuring out why we get NULL with --use-gl=desktop in the first place) is being
investigated in here: http://crbug.com/109010

http://crbug.com/109010