Fix Slimming Paint WebGL printing

Source/platform/graphics/GraphicsContext.cpp

Index: Source/platform/graphics/GraphicsContext.cpp
diff --git a/Source/platform/graphics/GraphicsContext.cpp b/Source/platform/graphics/GraphicsContext.cpp
index e8832f751376485789d34b37fcca5ecd61ed2709..732269412c26597cc3091a238f653864ff317d0e 100644
--- a/Source/platform/graphics/GraphicsContext.cpp
+++ b/Source/platform/graphics/GraphicsContext.cpp
@@ -1097,7 +1097,9 @@ void GraphicsContext::drawBitmapRect(const SkBitmap& bitmap, const SkRect* src,
     // Textures are bound to the blink main-thread GrContext, which can not be
     // used on the compositor raster thread.
     // FIXME: Mailbox support would make this possible in the GPU-raster case.
-    ASSERT(!isRecording() || !bitmap.getTexture());
+    // If we're printing it is safe to access the texture because we are always
+    // on main thread, even if the other conditions are not met.
+    ASSERT(!isRecording() || !bitmap.getTexture() || printing());

[chrishtr, 2015/05/20 18:20:40]

I assume that when slimming paint is off, and printing is on, the code that
generates an SkBitmap and passes it to drawBitmapRect always does so without a
texture. Is that right?

And if so, it seems we should have the same sort of logic with slimming paint.
Maybe the SkBitmap-creation logic checks for isRecording(), and we should check
for isRecording() || printing()?

[Stephen Chennney, 2015/05/20 18:30:13]

There is a texture during printing, probably because it's WebGL and there needs
to be a texture to capture the content. I'll look further into where this
texture comes from.
I'll look.

It is the case that the thing the assert is checking for, use of a texture off
the Blink main thread, is not a problem when printing. So on some fundamental
level the assert is too aggressive.

     if (contextDisabled())
         return;