Revert "Revert "Remove GrBackendRenderTargetDesc in favor of GrBackendRenderTarget.""

This reverts commit 807371c15bd742efb98a9df6e1dee73e8bda8af5.

Docs-Preview: https://skia.org/?cl=40260
Change-Id: I28e0434c455155ff39a5aaa4141abdf442474e87
Reviewed-on: https://skia-review.googlesource.com/40260
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>

2 files changed, 14 insertions, 13 deletions

diff --git a/site/user/sample/color.md b/site/user/sample/color.md
index 28d86d396d..3f4d869504 100644
--- a/site/user/sample/color.md
+++ b/site/user/sample/color.md
@@ -116,11 +116,9 @@ can be in any gamut, but must have a linear transfer function.
 	sk_sp<SkImage> MakeFromEncoded(sk_sp<SkData> encoded);
 	
 	// Create an image from a texture in a particular color space
-	// Caution: There are versions of this constructor that do not take an
-	//          SkColorSpace.  But without an SkColorSpace, Skia does not have
-	//          enough information to draw correctly.
-	sk_sp<SkImage> MakeFromTexture(GrContext*, const GrBackendTextureDesc&,
-	                               SkAlphaType, sk_sp<SkColorSpace>, ...);
+	sk_sp<SkImage> MakeFromTexture(GrContext*, const GrBackendTexture&,
+                                       GrSurfaceOrigin, SkAlphaType, sk_sp<SkColorSpace>,
+                                       ...);
 
 **SkBitmap** is another (not preferred) representation for image sources.  Be careful to not forget
 the color space.
@@ -190,4 +188,5 @@ cannot know how to draw without knowing the color space of the source.
 It is possible to create **an object that is both a source and destination**, if Skia will both
 draw into it and then draw it somewhere else.  The same rules from above still apply, but it is
 subtle that the color space tag could have an effect (or no effect) depending on how the object is
-used.
\ No newline at end of file
+used.
+
diff --git a/site/user/special/vulkan.md b/site/user/special/vulkan.md
index bba6968a95..14f44b846a 100644
--- a/site/user/special/vulkan.md
+++ b/site/user/special/vulkan.md
@@ -33,14 +33,16 @@ To create a GrContext that is backed by Vulkan the client creates a Vulkan devic
 
     sk_sp<GrContext> context = GrContext::MakeVulkan(vkBackendContext);
 
-When using the Vulkan backend the GrBackendObject field in
-GrBackendRenderTargetDesc and GrBackendTextureDesc is interpeted as a pointer
-to a GrVkImageInfo object. GrVkImageInfo specifies a VkImage and associated
-state (tiling, layout, format, etc). This allows the client to import
-externally created Vulkan images as destinations for Skia rendering via
-SkSurface factory functions or for to composite Skia rendered content using
-SkImage::getTextureHandle().
+When using the Vulkan backend, GrVkImageInfo is used to construct GrBackendTexture
+and GrBackendRenderTarget objects that in turn are used to create SkSurface and SkImage
+objects that refer to VkImages created by the Skia client.
 
+The GrBackendObject returned by SkImage::getTextureHandle(),
+SkSurface::getTextureHandle(), and SkSurface::getRenderTargetHandle() should be
+interpreted as a GrVkImageInfo*. This allows a client to get the backing VkImage
+of a SkImage or SkSurface.
+
+GrVkImageInfo specifies a VkImage and associated state (tiling, layout, format, etc).
 After getting a GrVkImageInfo* via getTextureHandle() or
 getRenderTargetHandle(), the client should check the fImageLayout field to know
 what layout Skia left the VkImage in before using the VkImage. If the client