This reverts commit d90777ada3.
Reason for revert: relanding with fix to GrBackendTexture
Original change's description:
> Revert "Remove GrBackendFormat's textureType use from isFormatTexturable call."
>
> This reverts commit 832c817bc8.
>
> Reason for revert: uninitialized value in GrBackendTexture
>
> Original change's description:
> > Remove GrBackendFormat's textureType use from isFormatTexturable call.
> >
> > The goal of this change was to remove the use of GrBackendFormat::textureType()
> > from GrCaps::isFormatTexturable call. Instead we will always pass in a
> > GrTextureType into this call.
> >
> > To do this a lot of plumbing of GrTextureType was added to various call
> > sites. However, this CL halts the plubming up at the proxy level where we
> > get it from the GrBackendFormat still. Future CLs will continue removing
> > these call sites and others that use GrBackendFormat::textureType().
> >
> > Bug: skia:12342
> > Change-Id: Ic0f02b9c7f7402405623b8aa31aa32a9a7c22297
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439277
> > Commit-Queue: Greg Daniel <egdaniel@google.com>
> > Reviewed-by: Brian Salomon <bsalomon@google.com>
>
> TBR=egdaniel@google.com,bsalomon@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
>
> Change-Id: I354bbbf00be7a86c480009f3e7b36a8777a6bf3a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:12342
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439338
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Greg Daniel <egdaniel@google.com>
# Not skipping CQ checks because this is a reland.
Bug: skia:12342
Change-Id: I151196f149f9e191d2975b8fe81334f4f8720744
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439339
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This reverts commit 832c817bc8.
Reason for revert: uninitialized value in GrBackendTexture
Original change's description:
> Remove GrBackendFormat's textureType use from isFormatTexturable call.
>
> The goal of this change was to remove the use of GrBackendFormat::textureType()
> from GrCaps::isFormatTexturable call. Instead we will always pass in a
> GrTextureType into this call.
>
> To do this a lot of plumbing of GrTextureType was added to various call
> sites. However, this CL halts the plubming up at the proxy level where we
> get it from the GrBackendFormat still. Future CLs will continue removing
> these call sites and others that use GrBackendFormat::textureType().
>
> Bug: skia:12342
> Change-Id: Ic0f02b9c7f7402405623b8aa31aa32a9a7c22297
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439277
> Commit-Queue: Greg Daniel <egdaniel@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=egdaniel@google.com,bsalomon@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I354bbbf00be7a86c480009f3e7b36a8777a6bf3a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12342
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439338
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
The goal of this change was to remove the use of GrBackendFormat::textureType()
from GrCaps::isFormatTexturable call. Instead we will always pass in a
GrTextureType into this call.
To do this a lot of plumbing of GrTextureType was added to various call
sites. However, this CL halts the plubming up at the proxy level where we
get it from the GrBackendFormat still. Future CLs will continue removing
these call sites and others that use GrBackendFormat::textureType().
Bug: skia:12342
Change-Id: Ic0f02b9c7f7402405623b8aa31aa32a9a7c22297
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439277
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
The main change here is just fusing the following three methods into recreateSKP:
deflateSKP
createCallbackContexts
createSKP
All the remaining changes are just API fallout from that.
Bug: skia:11728
Change-Id: Iae2ce65983ad56c8288bdc830e248394a0055bfb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389925
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
- Migrate our code to SkImage::MakePromiseTexture
- Have DDLTileHelper share one SKP and one set of promise images across all tiles.
- Disallow on-the-fly allocation of mips for promise textures.
Bug: skia:10286
Change-Id: Ie35976958454fc520f3c9d860e6285441260c9f7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/291938
Commit-Queue: Adlai Holler <adlai@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is the only place we provide a proxy from a SkImage other than
asView() and is only used in one place in the library. Add a utility
function to replace uses in tests based on asView().
Bug: skia:11208
Change-Id: Ica6eae6e5f153f208523331566acc0360925a20e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/373617
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit f1650efc55.
Reason for revert: fix for cpu/ddl configs
Original change's description:
> Revert "Test all YUVA image factories with different encoded origins."
>
> This reverts commit 2ba80af000.
>
> Reason for revert: new test fails ddl and cpu configs on imggen
>
> Original change's description:
> > Test all YUVA image factories with different encoded origins.
> >
> > Now that SkImage_GpuYUVA stores a GrYUVATextureProxies it supports
> > encoded origins.
> >
> > Modify wacky_yuv_format GMs to use different origins and remove
> > restriction in SkImage::MakeFromYUVAPixmaps.
> >
> > Bug: skia:10632
> > Change-Id: I02477d592b7baba164944d629eeac48223698c10
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353623
> > Reviewed-by: Jim Van Verth <jvanverth@google.com>
> > Commit-Queue: Brian Salomon <bsalomon@google.com>
>
> TBR=jvanverth@google.com,bsalomon@google.com
>
> Change-Id: If909ee4769cc1c74e1682a5e2870ec85a83f65c5
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:10632
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354661
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=jvanverth@google.com,bsalomon@google.com
# Not skipping CQ checks because this is a reland.
Bug: skia:10632
Change-Id: Iafe79ab5b3ce0ff9e3a4007e5d8fbc44edded196
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/355630
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:10632
Change-Id: If4dd7779b0856f6d0b441381bf7f2f51527cdb9d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/352497
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Previous approach using magick's -orient tool didn't actually change the
stored JPEG's orientation (they were all tagged Undefined and the data
was top-left).
Regenerate the images using new method where the PNGs are generated with
transformations that the EXIF tag will undo. The script converts to JPEG
using magick and then modifies the TAG using exiftool.
Change-Id: Ic2276711c0f4faa26620c93b24f4f0e58d658ae3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/345127
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Remove done and release distinction. Chrome is not using either as
it tracks texture access using other synchronization mechanisms
(semaphores, flush finish procs). Now there is just fulfill and release
where release is called when the texture can be deleted. Also,
release proc can be null.
Simplify texture idle mechanism as the "flushed" state was only used to
implement the old idea of a release proc. The "finished" idle state is
still used to implement the new release proc. Though, it could also be
removed if GrTexture were to be removed for textures returned by fulfill.
Not directly tied to this bug, but a new YUVA factory will be required
and it's good to clean things up first to avoid adding another
instance of the current complexity.
Bug: skia:10632
Change-Id: I4fe3c0af3f5a591506b1b3c736fd3284a38465a6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/331836
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is a reland of ed63444587
Original change's description:
> Add idea of DataType to SkYUVAPixmapInfo.
>
> DataType describes the data type of YUVA channels
> independent of how they are grouped into planes.
>
> Adds mapping functions between SkColorType/channel count
> and DataType.
>
> SkYUVAPixmapInfo can be constructed from DataType and will
> choose appropriate SkColorTypes for each plane.
>
> Valid SkYUVAPixmapInfos now have the same DataType for each
> plane (could relax this in the future, esp for alpha plane).
>
> SkYUVAPixmapInfo::SupportedDataTypes specifies the supported
> combinations of SkYUVAInfo::PlanarConfig and
> kYUVAPixmapInfo::DataType supported by a GrContext (based on
> supported texture formats).
>
> SkImageGenerator/SkCodec YUVA query API now takes a
> SupportedDataTypes.
>
> Change-Id: I8791234638e6ba3396d1e7960b7bc210edc6dd57
> Bug: skia:10632
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314276
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:10632
Change-Id: I35b55b7477c11c822fdb3729a9f84acff1eb785d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315284
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit ed63444587.
Reason for revert: trying to unblock android roller, which incorrectly thinks this has a merge conflict: https://b.corp.google.com/issues/167576324
Original change's description:
> Add idea of DataType to SkYUVAPixmapInfo.
>
> DataType describes the data type of YUVA channels
> independent of how they are grouped into planes.
>
> Adds mapping functions between SkColorType/channel count
> and DataType.
>
> SkYUVAPixmapInfo can be constructed from DataType and will
> choose appropriate SkColorTypes for each plane.
>
> Valid SkYUVAPixmapInfos now have the same DataType for each
> plane (could relax this in the future, esp for alpha plane).
>
> SkYUVAPixmapInfo::SupportedDataTypes specifies the supported
> combinations of SkYUVAInfo::PlanarConfig and
> kYUVAPixmapInfo::DataType supported by a GrContext (based on
> supported texture formats).
>
> SkImageGenerator/SkCodec YUVA query API now takes a
> SupportedDataTypes.
>
> Change-Id: I8791234638e6ba3396d1e7960b7bc210edc6dd57
> Bug: skia:10632
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314276
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,scroggo@google.com
Change-Id: I72c39539a4766f10cac3ca3cdef6c503a8319ff1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10632
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314895
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
DataType describes the data type of YUVA channels
independent of how they are grouped into planes.
Adds mapping functions between SkColorType/channel count
and DataType.
SkYUVAPixmapInfo can be constructed from DataType and will
choose appropriate SkColorTypes for each plane.
Valid SkYUVAPixmapInfos now have the same DataType for each
plane (could relax this in the future, esp for alpha plane).
SkYUVAPixmapInfo::SupportedDataTypes specifies the supported
combinations of SkYUVAInfo::PlanarConfig and
kYUVAPixmapInfo::DataType supported by a GrContext (based on
supported texture formats).
SkImageGenerator/SkCodec YUVA query API now takes a
SupportedDataTypes.
Change-Id: I8791234638e6ba3396d1e7960b7bc210edc6dd57
Bug: skia:10632
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314276
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Note: The polarity of the staging flag is inverted from usual because
a G3 dependency with no SkUserConfig.h relies on the legacy API.
Once this lands, we will migrate them and others, then remove the
staging API. The inverted staging flag is kind of nice, actually - I may
use that pattern in the future. It means less total CLs and it's just as
easy to flip the bit on or off during debugging.
Bug: skia:104662
Change-Id: I48cba1eeae3e2e6f79918c6d243e0666e68ec71b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/310656
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
SkYUVAPixmapInfo is a SkYUVAInfo with per-plane color types and row
bytes. It describes a set of pixmaps that make up a planar image.
Consolidates validity checks of the SkYUVAInfo with the color types
and row bytes. It can provide SkImageInfos for each plane and also
assist with configuring planes to share a common allocation.
SkYUVAPixmaps is a collection of SkPixmaps that are valid for a
SkYUVAInfo. It can either wrap existing SkPixmaps or allocate and
own the memory. It consolidates validity checking of SkPixmaps with
the SkYUVAInfo. Replaces sk_gpu_test::YUVAPixmaps.
Minor tweaks to SkYUVAInfo naming, parameter order consistency, adds a
hasAlpha() method.
Bug: skia:10632
Change-Id: Ib0f48b8448fff22805fd0c04e07887d0b7338b76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/312886
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
The old API is no longer implemented by SkCodecImageGenerator, meaning
we would never take the YUVA code path.
Bug: skia:10632
Change-Id: I33adb348768fdcd70368640d6857c5c7e3c2dc0f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/312882
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
https://clang.llvm.org/extra/clang-tidy/checks/performance-unnecessary-copy-initialization.html
Finds local variable declarations that are initialized using the copy
constructor of a non-trivially-copyable type but it would suffice to
obtain a const reference.
The check is only applied if it is safe to replace the copy by a const
reference. This is the case when the variable is const qualified or when
it is only used as a const, i.e. only const methods or operators are
invoked on it, or it is used as const reference or value argument in
constructors or function calls.
Change-Id: I1261410deccd8ea64e85edec53fbd5360940e587
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/308759
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
https://clang.llvm.org/extra/clang-tidy/checks/readability-const-return-type.html
`const` on a non-pointer/reference return type typically doesn't add
value and can have negative side effects. (i.e., returning a
`const std::string` isn't meaningfully different from returning a
`std::string`, but can sometimes inhibit move-related optimizations.)
In Skia's case, the priv() functions are a notable exception where const
return types are intentional and valuable. These calls have been marked
with NOLINT to exclude them from the check.
This check does not affect pointer and reference returns, where
constness is important.
Change-Id: I86cab92332f164e5ab710b4127182eec99831d7d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/308564
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: Ib509a55c488bab1df49e24e662c56fd2343bd64b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/308427
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Before I start updating this to support relocatable DDLs I felt I
should clean it up a bit.
Change-Id: I640d15a40164b33c4c2d7378e37d39fe7d3ff313
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300926
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
External clients will eventually have to call this to get access
to a direct context from an SkCanvas or SkSurface (which will
only have 'recordingContext' accessors).
Bug: skia:10441
Change-Id: I10e34081277b685fa59d03e1fce1887f3524e0fa
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300178
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
So apparently I did all the work to allow us to not submit in
updateBackendTexture, but then I never actually removed the submit...
Bug: chromium:1087124
Change-Id: Id08a9c5e116cff57dbbeada74186f94da6e28656
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297866
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
The callback lets the caller know when the data uploads to the texture
from the create call are finished. This is important since the caller
cannot delete the backend texture till the gpu is finished on vulkan
and d3d.
This change also removes the hard sync in vulkan during creation.
Change-Id: I660d142219474e22b1337d2b0c81cda66fe18a4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/286517
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Besides better matching Viz's behavior this also reduces a lot of choppiness in the composition RenderTask DAG.
In the previous approach DDL draws and compositing draws would be interleaved resulting in a lot of render target swaps.
This necessitated some reorganization bc I wanted to reuse PromiseImageCallbackContext to manage the tiles' promiseImages.
Change-Id: I513bf060a69ff2bfe0e7b82ae72f149dfede632e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/285056
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
SkMipMap::Build fails surprisingly often. Fall back to unmipped promise images in that case.
The prior approach created the mipMaps too late (i.e., at backendTexture creation time) for the test harness to change its mind about the mip status of a promise image. This approach moves the mipmap creation earlier - to when the PromiseImageInfos are created (i.e., at SKP deflation time).
Change-Id: Id3c67a44cc84da7ee76d02f4d44d7f27ce8e39d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/284136
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
When timing DDL performance with SKPs, if the mipmapping requirements of a given SkImage are gotten wrong at record time, the mipmaps will keep getting regenerated over and over again. This CL works around the problem by just creating all promise images as mipmapped. A better (but longer term solution) would be to examine the actual draw ops w/in an SKP.
Even more aggressively, we may want to disable mipmap regeneration w/in DDLs.
For desk_nytimes.skp on Windows/gl we have:
before CL after CL
w/ DDLs 7.999 3.136
w/o DDLs 1.953 1.863
This perf improvement won't be seen by Chrome since, presumably, they're creating their backend textures w/ the correct mipmappedness. Additionally, they, hopefully, aren't recording the same DDL over and over again (with incorrect mipmappedness).
Bug: 1056730
Change-Id: I8bf9dc9e64bc77159a04d89e5e3ac398e98beaa7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/283677
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
With the addition of the DDL program pre-compilation we need to know how it is working.
This CL also fixes some threading bugs.
Bug: skia:9455
Change-Id: I20da58a7f1b19685687fae1d159d4e0db8a4964d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/273001
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Split apart creation of the callback contexts and the backend textures
This allows the texture upload to be done separately on the
gpu-thread
Add a backendFormat member to the promise image callback context
This allows the promise images to be created in CreatePromiseImages
before the backend textures have been created (i.e., the backend
textures can now be created on the gpu-thread so we have no
guarantee they will be available when the SKP is being reinflated
w/ promise images)
Change-Id: I1e21385e450a5ef27dd6950d9d6aee737aa7515d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/270939
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This fixes the proximal issue w/ the new DDL images. The underlying issue appears to be that the GIF decoder isn't available on all platforms.
Change-Id: I117b6460e09b2c7815d84929a340579690c15945
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/260276
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Everything except for SkImageInfo.h is mechanical
Change-Id: I2d775c79467fb15f6022e80d21b4a9151272fe2a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/242896
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This makes calling GrCaps::getBackendFormatFromColorType equivalent to calling GrContext::defaultBackendFormat
Change-Id: Ic402245fa0502920c47c2a29aadc4e559abdc09b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/230416
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This CL allows user to indicate that they have a protected content in
GrVkBackendContext creation which results in protected CommandPool and Queue
usage.
Bug: skia:9016
Change-Id: I6a478d688b6988c2c5e5e98f18f58fb21f9d26ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/210067
Commit-Queue: Greg Daniel <egdaniel@google.com>
Auto-Submit: Emircan Uysaler <emircan@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
We want the non-color, non-pixel-data version of createBackendTexture to truly create uninitialized textures.
Change-Id: I08867508ea181b7ba3685638cc7a3ea11d527a24
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218396
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
