Refactor to separate backend object lifecycle and GpuResource budget decision

include/gpu/GrTypes.h

Index: include/gpu/GrTypes.h
diff --git a/include/gpu/GrTypes.h b/include/gpu/GrTypes.h
index 47c13ec02d91888bcd8d0738862976847f09e2b3..ed00774c03b802e3be77536d93e4b03eecbc2da9 100644
--- a/include/gpu/GrTypes.h
+++ b/include/gpu/GrTypes.h
@@ -425,6 +425,29 @@ GR_MAKE_BITFIELD_OPS(GrSurfaceFlags)
 // opaque type for 3D API object handles
 typedef intptr_t GrBackendObject;
 
+enum class GrBackendObjectLifeCycle {

[bsalomon, 2016/04/19 14:37:46]

Seems a bit concusing that we call this BackendObjectLifeCycle but it isn't just
used for wrapped backend objects and has a kInternal value. Also, even though I
created it I never loved the term LifeCycle. Would GrResourceOwnership make more
sense here?


It also seems like this and GrWrapOwnership are mostly redundant, this just adds
the kInternal value.. What about unifying them and making public wrap methods
fail if kInternal is passed?

[Kimmo Kinnunen, 2016/04/20 12:04:55]

The "backend object" here means GL object or Vulkan object, not "wrapped"
status. I'll update the comments further to make the distinction.

 "backend object" -> GL int
 "resource" -> Skia resource cache item

It is used for all backend object references, where the ownership is
customizable.
Renamed it to GrBackendObjectOwnership.

Maybe this "wrapped" vs "this is resource should be destroyed" confusion is not
going away unless the interface is factored to its logical but verbose
conclusion. 

Is the new code taking it too far?
Originally I moved away from "Resource", as it would imply GrGpuResource
ownership, which GrBackendObjectOwnership is not. 
Personally I prefer them separate, as they represent different things. I don't
see much savings from removing one. Anyhow, I made the thing even more verbose,
and at the same time nullifying this unification opportunity.

I think GrWrapOwnership::kAdopt_GrWrapOwnership is the source of complexity
here. It does not seem very consistent with the rest of the API, as such
semantics are not available for all the wrap calls. One way to simplify things
is to remove it, if only possible. 

+    /**
+     * The object is created and owned by Skia. Objects with this status may be kept alive
+     * by the cache as either part of scratch or unique resources even when there are no refs to
+     * the resources.
+     * The cache may release the resources whenever there are no refs.
+     */
+    kInternal,
+
+    /**
+     * Skia does not manage the lifetime of the backend 3D API object. The client is
+     * responsible for freeing the object. Used to inject client- created GPU resources into Skia
+     * (e.g. to render to a client-created texture).
+     */
+    kBorrowed,
+
+    /**
+     * An external object with ownership transfered into Skia. Skia will free the object.
+     */
+    kAdopted
+};
+
+
 /**
  * Some textures will be stored such that the upper and left edges of the content meet at the
  * the origin (in texture coord space) and for other textures the lower and left edges meet at