Skia side RGB to YUV gpu conversion

include/core/SkImageGenerator.h

 /*
  * Copyright 2013 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef SkImageGenerator_DEFINED
 #define SkImageGenerator_DEFINED
 
@@ skipping 98 matching lines @@
      */
     bool getPixels(const SkImageInfo& info, void* pixels, size_t rowBytes,
                    SkPMColor ctable[], int* ctableCount);
 
     /**
      *  Simplified version of getPixels() that asserts that info is NOT kIndex8_SkColorType.
      */
     bool getPixels(const SkImageInfo& info, void* pixels, size_t rowBytes);
 #endif
 
+    struct YUV8Planes {
+        // do we want/need per-buffer rowbytes? or just assume tight?
+        SkImageInfo fInfo;

[sugoi1, 2014/07/08 14:42:02]

The SkImageInfo member is required so that onGetYUV8Planes() can call
onGetPixels(). I could also take it out of this structure and pass it directly
to onGetYUV8Planes() as an extra argument to that function. I put it here
because it is not required when the YUV8Planes argument is NULL in
onGetYUV8Planes().

+        uint8_t*    fPixels;

[sugoi1, 2014/07/08 14:42:02]

The current implementation in Blink makes it very hard to have 3 buffers, so I
reverted this back to a single buffer into which the YUV components will be
stored sequentially. This can be changed, depending on how we choose to handle
changes to ImageFrameGenerator::ExternalMemoryAllocator.

+    };
+    /**
+     *  If planes is NULL, this imagegenerator should output the sizes and return true
+     *  if it can efficiently return YUV planar data. If it cannot, it should return false.
+     *
+     *  If planes is not NULL, then it should copy the associated Y,U,V data into those planes
+     *  of memory supplied by the caller. It should validate that the sizes match what it expected.
+     *  If the sizes do not match, it should return false.
+     */
+    bool getYUV8Planes(SkISize* sizes, const YUV8Planes* planes = NULL);

[Stephen White, 2014/07/08 15:00:19]

Does "planes" have to be a default parameter? It might be slightly clearer if it
was explicitly specified at the callsite, to distinguish the "please fill" from
"just the sizes, ma'am" flavours. Don't have a strong feeling, just a slight
preference against default params.

[reed1, 2014/07/08 15:08:52]

What about

struct Plane8 {
    uint8_t* fPixels;
    size_t fRowBytes;
};

getYUV8Planes(SkISize sizes[3], Plane8 planes[3]);

I think adding rowbytes *might* be needed, and certainly doesn't hurt. I don't
see any reason to add SkImageInfo to a plane.

+
 protected:
     virtual SkData* onRefEncodedData();
     virtual bool onGetInfo(SkImageInfo* info);
     virtual bool onGetPixels(const SkImageInfo& info,
                              void* pixels, size_t rowBytes,
                              SkPMColor ctable[], int* ctableCount);
+    virtual bool onGetYUV8Planes(SkISize*, const YUV8Planes*);
 };
 
 #endif  // SkImageGenerator_DEFINED