Fixes for piping bitmaps with encoded data.

Fixes for piping bitmaps with encoded data.

Eliminates some spew from gm when running while providing a resource
path.

SkGPipe:
Instead of calling SkBitmap::flatten and SkBitmap::unflatten, call
SkOrderedWriteBuffer::writeBitmap and SkOrderedReadBuffer::readBitmap,
which will allow reading and writing bitmaps with encoded data.

Provide an option to set a function on SkGPipeReader for decoding
bitmaps that have encoded data.

SamplePipeControllers:
Set an option to use a function for decoding bitmaps on both
PipeController and TiledPipeController.

gmmain:
Use a function for decoding bitmaps when deserializing a picture from
a stream and when using SkGPipe. This results in successes for factory
GM.

SampleApp.cpp:
Set a bitmap decoding function on SimplePC and TiledPipeController.
Allows running GM:factory to work properly.

[reed1, 2013-04-23 21:14:36]

lgtm

[scroggo, 2013-04-24 20:46:56]

The first patch actually resulted in a crash in gm for other GMs, so I did not
submit. New patch fixes that crash.

[scroggo, 2013-04-25 17:02:46]

Adding Derek.

We should discuss this more in person, but I want to try and add some
explanation of what's going on here as well.

<background>
Patch set 1 fixes a bug in SkGPipe when using the cross-process flag and trying
to draw an SkBitmap whose pixels are backed by an SkLazyPixelRef. In
cross-process mode, the SkBitmapHeap uses external storage. The implementation
for external storage is SkGPipeCanvas::shuttleBitmap, which flattens SkBitmaps
to send them to the reader (with the tag kDef_Bitmap_DrawOp), who then
unflattens them.

An SkBitmap whose pixels are backed by an SkLazyPixelRef does not get recreated
by the reader, because SkLazyPixelRef does not implement flatten, so the reader
has no way to unflatten it. One solution would be to implement flatten and
unflatten on SkLazyPixelRef. This has two downsides:

1. SkLazyPixelRef
(https://code.google.com/p/skia/source/browse/trunk/src/lazy/SkLazyPixelRef.h)
is currently written to require an SkImageCache. The SkImageCache handles
allocating pixel memory when it's time to decode and throwing it away (under
memory pressure or when it's no longer needed). When writing one to the stream,
I do not think it makes sense to tell the stream what the cache is like.* 

2. It will not solve the problem for SkPixelRef subclasses in Chrome with
encoded data, since they currently do not implement flatten either, and we
wouldn't be able to unflatten even if they did. Maybe this is not a problem
we'll actually encounter though.

Instead, I decided to place a decoding function pointer in SkGPipeReader the
same way deserializing SkPictures allows a function pointer. This gives the
reader flexibility (simply decoding or using some sort of lazy decoding, for
example). In order to make this work, I had to make two small changes:

1. SkGPipeCanvas::shuttleBitmap calls SkOrderedWriteBuffer::writeBitmap instead
of SkBitmap::flatten(SkBitmap) (which would not have flattened the
SkLazyPixelRef).
2. SkGPipeState::addBitmap now calls SkOrderedReadBuffer::readBitmap instead of
SkBitmap::unflatten.

Now, when the SkLazyPixelRef is drawn to the SkGPipeCanvas, writeBitmap does the
right thing - it writes the encoded data to the stream. The SkGPipeReader calls
readBitmap, and now that its SkOrderedReadBuffer has a bitmap decoding function
pointer, it uses it to decode the bitmap. Success!
</background>

As Mike expected, when the reader sees a command op code that says drawBitmap,
it sees an index, and asks the SkGPipeState for the SkBitmap that matches that
index. There's no confusion about unflattening or decoding, because drawBitmap
directly calls the SkGPipeState for bitmap(i). The tricky part comes in when
flattening an SkBitmapProcShader:

In SkGPipeCanvas::writePaint, each SkFlattenable associated with the SkPaint is
flattened before sending it to the reader. So SkBitmapProcShader::flatten is
called, which calls SkOrderedWriteBuffer::writeBitmap on its internal SkBitmap.
Just like in the drawBitmap case, this SkBitmap is inserted into the heap. Since
the SkGPipe is cross-process, it again goes to external storage, which means
writing the tag kDef_Bitmap_DrawOp and flattening the SkBitmap. Prior to patch
set 1 this was done via SkBitmap::flatten, but now it is done using
SkOrderedWriteBuffer::writeBitmap, so it can write an SkBitmap with encoded
data. A confusing aspect is that writeBitmap has been called within a call to
writeBitmap. The first SkOrderedWriteBuffer had the SkBitmapHeap attached to it,
so it writes an index, but the second one (which serializes it to cross the
process boundary and be read by the SkGPipeReader) does not, so it flattens to
the stream or writes the encoded data. The second one's result also gets written
to the stream first:

kDef_Bitmap_DrawOp (with an index, and the flattened/encoded data)
Flattenable (with an index referring to the bitmap above)

On the reader side, SkGPipeState sees kDef_Bitmap_DrawOp and adds it to its
list. Then it sees kDef_Flattenable_DrawOp, so it unflattens the flattenable. In
SkBitmapProcShader's constructor, it calls SkBitmap::unflatten. This is the only
reason SkGPipeState implements SkBitmapHeapReader (which means that its
SkBitmaps can be accessed like an SkBitmapHeap, but it doesn't do any of the
messy work of comparing on insertion). Because writing the flattenable stored an
index, the SkOrderedReadBuffer needs to have an SkBitmapHeapReader to find the
SkBitmap at that index. Unfortunately, this means that in
SkGPipeState::addBitmap, which reads the same SkOrderedReadBuffer (and used to
call SkBitmap::unflatten), SkOrderedReadBuffer::readBitmap sees that it has an
SkBitmapHeapReader attached - the SkGPipeState itself! - and calls getBitmap on
the next uint32_t (which happens to be the width of a flattened SkBitmap).

I solved with the code in patch set 2, which removes the SkBitmapHeapReader and
then reattaches it. An alternate solution (to this problem) would be to add more
info to read/writeBitmap. Instead of just assuming that the reader will supply
an SkBitmapHeapReader if it's needed, we could add a boolean to state whether
the rest of the data is an index or the beginning of flattened data. Then we can
throw an error if the SkBitmapHeapReader is needed and not supplied.

*Why it does not make sense to flatten the cache:
- Any pixel memory in the cache is redundant with the encoded data. The point in
flattening is to make the data smaller, and the encoded data already satisfies
that.
- The reader may not have the same memory requirements, so it does necessarily
not make sense to recreate a cache with similar behavior.
- Flattening the cache to recreate it by the reader would require our writer and
reader to know a lot about SkImageCache, which I think should be orthogonal.

[reed1, 2013-04-25 17:08:16]

1. We *so* need an arch. diagram/doc to capture all of this great explanation
for how skia "flattens" bitmaps.

2. Seems to me that such an additional param might be a good idea, since it
makes the call-sites take a little more declarative responsibility (but will
reserve a real opinion until leon tries it or thinks more about it).

[scroggo, 2013-04-25 18:47:30]

On 2013/04/25 17:08:16, reed1 wrote:
> 1. We *so* need an arch. diagram/doc to capture all of this great explanation
> for how skia "flattens" bitmaps.
> 
> 2. Seems to me that such an additional param might be a good idea, since it
> makes the call-sites take a little more declarative responsibility (but will
> reserve a real opinion until leon tries it or thinks more about it).

I think the only downside to this is that I have to bump the PICTURE_VERSION. In
general I think it's a good solution. See
https://codereview.chromium.org/14230022/

[scroggo, 2013-04-29 17:35:49]

Closed in favor of the above referenced CL