Attempt to somewhat simplify GrContext::readSurfacePixels interaction with GrGpu.

src/gpu/GrGpu.h

 /*
  * Copyright 2011 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef GrGpu_DEFINED
 #define GrGpu_DEFINED
 
@@ skipping 115 matching lines @@
      *
      * @return The index buffer if successful, otherwise NULL.
      */
     GrIndexBuffer* createIndexBuffer(size_t size, bool dynamic);
 
     /**
      * Resolves MSAA.
      */
     void resolveRenderTarget(GrRenderTarget* target);
 
+    /** Info struct returned by getReadPixelsInfo about performing intermediate draws before 
+        reading pixels for performance or correctness. */
+    struct ReadPixelTempDrawInfo {
+        /** If the GrGpu is requesting that the caller do a draw to an intermediate surface then
+            this is descriptor for the temp surface. The draw should always be a rect with
+            dst 0,0,w,h. */
+        GrSurfaceDesc   fTempSurfaceDesc;
+        /** Indicates whether there is a performance advantage to using an exact match texture
+            (in terms of width and height) for the intermediate texture instead of approximate. */
+        bool            fUseExactScratch;
+        /** The caller should swap the R and B channel in the temp draw and then instead of reading
+            the desired config back it should read GrPixelConfigSwapRAndB(readConfig). The swap
+            during the draw and the swap at readback time cancel and the client gets the correct
+            data. The swapped read back is either faster for or required by the underlying backend
+            3D API. */
+        bool            fSwapRAndB;
+    };
+    /** Describes why an intermediate draw must/should be performed before readPixels. */
+    enum DrawPreference {
+        /** On input means that the caller would proceed without draw if the GrGpu doesn't request
+            one.
+            On output means that the GrGpu is not requesting a draw. */
+        kNoDraw_DrawPreference,

[robertphillips, 2015/07/23 13:04:23]

space between 'client' and 'would' ?

[bsalomon, 2015/07/23 13:43:59]

Done.

+        /** Means that the clientwould prefer a draw for performance of the readback but
+            can satisfy a straight readPixels call on the inputs without an intermediate draw.
+            getReadPixelsInfo will never set the draw preference to this value but may leave
+            it set. */
+        kCallerPrefersDraw_DrawPreference,
+        /** On output means that GrGpu would prefer a draw for performance of the readback but
+            can satisfy a straight readPixels call on the inputs without an intermediate draw. The
+            caller of getReadPixelsInfo should never specify this on intput. */
+        kGpuPrefersDraw_DrawPreference,

[robertphillips, 2015/07/23 13:04:23]

Can we also disallow kRequireDraw as input?

[bsalomon, 2015/07/23 13:43:59]

It isn't currently being used by the caller, but I can imagine how it would be
(we wanted to do a data transformation before reading that doesn't have a sw
implementation). If restricting it would simplify the code at all I'd be for it,
but I think it'd be an added assertion. The restriction on kGpu was just because
it's nonsensical for the caller to declare it, other than the assertion it
doesn't cause a correctness problem.

The reason I split kCallerPrefers and kGpuPrefers was so that when the unpremul
step couldn't be done on the GPU, the caller can know whether there was any
additional reason to do the draw or that it should skip the draw and do a
straight read.

+        /** On input means that the caller requires a draw to do a transformation and there is no
+            CPU fallback.
+            On output means that GrGpu can only satisfy the readPixels request if the intermediate
+            draw is performed.
+          */
+        kRequireDraw_DrawPreference
+    };
+
+    /** Used to negotiates whether and how an intermediate draw should or must be performed before
+        a readPixels call. If this returns false then GrGpu could not deduce an intermediate draw
+        that would allow a successful readPixels call. */
+    virtual bool getReadPixelsInfo(GrSurface* srcSurface, int readWidth, int readHeight,
+                                   size_t rowBytes, GrPixelConfig readConfig, DrawPreference*,
+                                   ReadPixelTempDrawInfo *) = 0;
+
     /**
-     * Gets a preferred 8888 config to use for writing/reading pixel data to/from a surface with
+     * Gets a preferred 8888 config to use for writing pixel data to a surface with
      * config surfaceConfig. The returned config must have at least as many bits per channel as the
-     * readConfig or writeConfig param.
+     * writeConfig param.
      */
-    virtual GrPixelConfig preferredReadPixelsConfig(GrPixelConfig readConfig,
-                                                    GrPixelConfig surfaceConfig) const {
-        return readConfig;
-    }
     virtual GrPixelConfig preferredWritePixelsConfig(GrPixelConfig writeConfig,
                                                      GrPixelConfig surfaceConfig) const {
         return writeConfig;
     }
 
     /**
      * Called before uploading writing pixels to a GrTexture when the src pixel config doesn't
      * match the texture's config.
      */
     virtual bool canWriteTexturePixels(const GrTexture*, GrPixelConfig srcConfig) const = 0;
 
     /**
-     * OpenGL's readPixels returns the result bottom-to-top while the skia
-     * API is top-to-bottom. Thus we have to do a y-axis flip. The obvious
-     * solution is to have the subclass do the flip using either the CPU or GPU.
-     * However, the caller (GrContext) may have transformations to apply and can
-     * simply fold in the y-flip for free. On the other hand, the subclass may
-     * be able to do it for free itself. For example, the subclass may have to
-     * do memcpys to handle rowBytes that aren't tight. It could do the y-flip
-     * concurrently.
-     *
-     * This function returns true if a y-flip is required to put the pixels in
-     * top-to-bottom order and the subclass cannot do it for free.
-     *
-     * See read pixels for the params
-     * @return true if calling readPixels with the same set of params will
-     *              produce bottom-to-top data
-     */
-     virtual bool readPixelsWillPayForYFlip(GrRenderTarget* renderTarget,
-                                            int left, int top,
-                                            int width, int height,
-                                            GrPixelConfig config,
-                                            size_t rowBytes) const = 0;
-     /**
-      * This should return true if reading a NxM rectangle of pixels from a
-      * render target is faster if the target has dimensons N and M and the read
-      * rectangle has its top-left at 0,0.
-      */
-     virtual bool fullReadPixelsIsFasterThanPartial() const { return false; };
-
-    /**
      * Reads a rectangle of pixels from a render target.
      *
      * @param renderTarget  the render target to read from. NULL means the
      *                      current render target.
      * @param left          left edge of the rectangle to read (inclusive)
      * @param top           top edge of the rectangle to read (inclusive)
      * @param width         width of rectangle to read in pixels.
      * @param height        height of rectangle to read in pixels.
      * @param config        the pixel config of the destination buffer
      * @param buffer        memory to read the rectangle into.
@@ skipping 278 matching lines @@
     GrTraceMarkerSet                                                    fActiveTraceMarkers;
     GrTraceMarkerSet                                                    fStoredTraceMarkers;
     // The context owns us, not vice-versa, so this ptr is not ref'ed by Gpu.
     GrContext*                                                          fContext;
 
     friend class GrPathRendering;
     typedef SkRefCnt INHERITED;
 };
 
 #endif