include/private:
- SkAutoTArray, SkAutoTMalloc no longer use bare pointers to owned memory,
- SkTHash and SkAutoTArray are now std::move()able.
- SkAutoTArray::swap no longer neccesary.
- SkAutoTMalloc::operator=() defined.
src/pdf:
- SkPDFCanon and SkPDFObjectSerializer are now std::move()able.
- `template <class T> static void renew(T* t) { t->~T(); new (t) T; }` is gone.
Change-Id: I2f36a0780c47d1427a85da240121c898387fb4cf
Reviewed-on: https://skia-review.googlesource.com/123401
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
When debugging DDL it is useful to just see which ops are being drawn instead of the entire reordering history.
Change-Id: I89708fecbd53c097b00e65b0da426bfb8046b0ee
Reviewed-on: https://skia-review.googlesource.com/122780
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This adds explicit overflow checks to the two likeliest
places where non-buggy code could overflow SkTDArray.
We have an #ifdef'd out PathMeasure_explosion GM that
overflows before this CL and aborts with it.
Bug: skia:7674
Change-Id: Ia0c430f4a8bb9bad687d13c875f604fd7da45aab
Reviewed-on: https://skia-review.googlesource.com/122342
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We already assert that setCount()'s argument is non-negative.
This does the same for setReserve().
There was one call site I could find that was actually sometimes
passing negative values to setReserve(), guarded here.
Already reviewed: https://skia-review.googlesource.com/c/skia/+/115982
Change-Id: Ia52a286732bf4056e9baf09555d27bab9abf2554
Reviewed-on: https://skia-review.googlesource.com/122305
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It's only used in one call site, which is clearer without it.
Already reviewed: https://skia-review.googlesource.com/c/skia/+/115982
Change-Id: I3d0f8c1f0756e01e29cdb9f9328b0f557d3650d3
Reviewed-on: https://skia-review.googlesource.com/122302
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Overriding bits of the paint was added with keyboard bindings but
without being reflected in the GUI. This adds these flags to the GUI.
Change-Id: I633801fb776248952afe7cbe8857676ef8b57135
Reviewed-on: https://skia-review.googlesource.com/121796
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
We will not allocate new mips on a wrapped texture but we will use mips
if the wrapped texture already has one. If we need mips for a draw this
will trigger a copy to occur.
Also some cleanup up of our InternalSurfaceFlags in general.
Bug: skia:7806
Change-Id: I7aa666478cc91bba6e0644b323825fcc9b49793a
Reviewed-on: https://skia-review.googlesource.com/121348
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
The big api level change here is that the getBackendInfo calls now return by value
instead of a pointer. These changes are being made in support of Vulkan so that
the client can update the VkImageLayout on the GrBackendTexture and have that
update get reflected in our internal tracking of the image. This is done by storing
a ref counted GrVkImageLayout object on the GrBackendTexture and the GrVkImage.
Bug: skia:
Change-Id: I8c6158fd3a66eb61fef97ebf09ea5364bca3f1ae
Reviewed-on: https://skia-review.googlesource.com/119101
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This reverts commit 80e1d56e19.
Reason for revert: SkRTree.cpp:57 asserting, probably this?
Original change's description:
> implement SkTDArray with std::vector
>
> It's always worth seeing if we can get away with replacing custom data
> structures with ones from the standard library. Our array-like types
> are all good candidates to replace with std::vector, and it's especially
> easy to start with SkTDArray. Unlike the others, it has no preallocated
> S-variant, which is tricky to make work with std::vector.
>
> SkTDArray also has known integer overflow bugs, leading to out of range
> writes. It'd be _very_ nice to ditch it for a better standard vector.
>
> I removed a bunch of unused or little-used methods, and updated a couple
> call sites that used methods in unusual or dangerous ways.
>
> I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just
> a touch to work within the constraints of an std::vector impl. It's not
> intended to be legal to write to the reserved-but-not-counted elements
> of an SkTDArray, but you can get away with it in our old implementation.
> This version now uses setCount() to actually reserve and count them, and
> should have the same performance and use the same amount of memory.
>
> The PathMeasure_explosion GM I added recently to reproduce this bug now
> draws without triggering undefined behavior or ASAN errors, provided you
> have ~40GB of RAM.
>
> Bug: skia:7674
>
> Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e
> Reviewed-on: https://skia-review.googlesource.com/115982
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com
Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7674
Reviewed-on: https://skia-review.googlesource.com/117901
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 7dd8ee9c60.
Reason for revert: going to revert primary CL
Original change's description:
> In older STLs, std::vector::insert() returns void.
>
> CQ_INCLUDE_TRYBOTS=skia.primary:Build-Debian9-Clang-arm-Debug-Chromebook_GLES
>
> Change-Id: I7bd15ecc7122965db16fbb51e51ee166b05dce2f
> Reviewed-on: https://skia-review.googlesource.com/117722
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,brianosman@google.com
Change-Id: I9c126edbef74293d8e7a2b7e2365e464ba367ae5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: skia.primary:Build-Debian9-Clang-arm-Debug-Chromebook_GLES
Reviewed-on: https://skia-review.googlesource.com/117900
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
CQ_INCLUDE_TRYBOTS=skia.primary:Build-Debian9-Clang-arm-Debug-Chromebook_GLES
Change-Id: I7bd15ecc7122965db16fbb51e51ee166b05dce2f
Reviewed-on: https://skia-review.googlesource.com/117722
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It's always worth seeing if we can get away with replacing custom data
structures with ones from the standard library. Our array-like types
are all good candidates to replace with std::vector, and it's especially
easy to start with SkTDArray. Unlike the others, it has no preallocated
S-variant, which is tricky to make work with std::vector.
SkTDArray also has known integer overflow bugs, leading to out of range
writes. It'd be _very_ nice to ditch it for a better standard vector.
I removed a bunch of unused or little-used methods, and updated a couple
call sites that used methods in unusual or dangerous ways.
I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just
a touch to work within the constraints of an std::vector impl. It's not
intended to be legal to write to the reserved-but-not-counted elements
of an SkTDArray, but you can get away with it in our old implementation.
This version now uses setCount() to actually reserve and count them, and
should have the same performance and use the same amount of memory.
The PathMeasure_explosion GM I added recently to reproduce this bug now
draws without triggering undefined behavior or ASAN errors, provided you
have ~40GB of RAM.
Bug: skia:7674
Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e
Reviewed-on: https://skia-review.googlesource.com/115982
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Ib3e2661d0383bf154bc9178dac070dfd910a393c
Reviewed-on: https://skia-review.googlesource.com/115200
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These are unused, and would make it conceptually tricky to replace
with something like std::vector that does not have a .release() method.
Change-Id: Iaee913d6a513d078989166c6e97097eeec0100ba
Reviewed-on: https://skia-review.googlesource.com/115921
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
For DDLs, Ganesh needs to know about External & Rectangle textures prior to instantiation (or PromiseImage fulfillment). These new flags allow the client to provide this information when the lazyProxy is created.
The new texture flags work analogously to the render target flags:
GrSurface and GrSurfaceProxy get a new set of accessors for the new flags
The new flags are set appropriately on a GrGLTexture when it is created
For wrapped texture proxies the flags are just copied off of the GrSurface
For lazy-proxies/promise-images the flags are computed up front and passed to the proxy
The GrSurfaceProxy/GrSurface flags equivalence is verified in GrSurfaceProxy::assign
Change-Id: Ia8e1998aa0a36ce4481bfd9e56be21f990e83148
Reviewed-on: https://skia-review.googlesource.com/114985
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL:
moves GrRenderTarget::fFlags to GrSurface::fSurfaceFlags
adds a GrInternalSurfaceFlags type and uses it for GrSurfaceProxy::fSurfaceFlags
The goal of this is to provide a location where GrTexture/GrTextureProxy-specific flags
(i.e., isExternal & isRectangle) can be stored.
Change-Id: I8df7b79036a6853dd378ff6cf10d4b37c60dd511
Reviewed-on: https://skia-review.googlesource.com/114796
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
The first bytes of the data always refer to the pixel accessed by texture coord (0, 0).
Change-Id: I708702d90f35b3bc896a48c3c3fd6a0be73f505a
Reviewed-on: https://skia-review.googlesource.com/112261
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This field has no interpretation at the GrTexture/GrGpu as the orientation is
handled at the GrSurfaceProxy level.
This change requires GrGpu to accept a GrSurfaceOrigin when creating a texture with initial data. The origin refers to the texel data to be uploaded. Longer term the plan is to remove this and require the data to be kTopLeft. Additionally, kBottomLeft will only be allowed for wrapped texture/RTs as this evolves.
Change-Id: I7d25b0199aafd9bf3b74c39b2cae451acadcd772
Reviewed-on: https://skia-review.googlesource.com/111806
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit ded47a5014.
Bug: skia:
Change-Id: I7d7552e6ccc8591cae91426407ab13b628b93b68
Reviewed-on: https://skia-review.googlesource.com/111760
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
For the DDLContexts we simply want to reuse the threadSafeProxy from the main thread but we, obviously, still need to create one for the main DirectContext.
TBR=bsalomon@google.com
Change-Id: I99449bc375172c9004e2e80c21d95ab2d7708309
Reviewed-on: https://skia-review.googlesource.com/110781
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 44b61204d9.
Reason for revert: TSAN bot crashing
Original change's description:
> Add 1010102 support to Ganesh
>
> Adds gl1010102, gles1010102, vk1010102, and mtl1010102
> configs to DM.
>
> This uses the same saveLayer approach as CPU, switching
> to 8888 so that we have enough alpha precision.
>
> Change-Id: I9f5b63747ec01031c8db97dadfc42f77e4863ccb
> Reviewed-on: https://skia-review.googlesource.com/110500
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: I782e740763044c1ae78fb219161e37eec7617c74
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/111580
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Adds gl1010102, gles1010102, vk1010102, and mtl1010102
configs to DM.
This uses the same saveLayer approach as CPU, switching
to 8888 so that we have enough alpha precision.
Change-Id: I9f5b63747ec01031c8db97dadfc42f77e4863ccb
Reviewed-on: https://skia-review.googlesource.com/110500
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
For the GrDrawOpAtlas:
At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
It now carries a GrProxyProvider for when it needs to create an atlas
It passes in a GrResourceProvider* at flush time to allow instantiation.
It does not, yet, allocate that GrDrawOpAtlases it might ever require.
TBR=bsalomon@google.com
Change-Id: I276d339d81e7b709140e082a7b58c5584f73ab70
Reviewed-on: https://skia-review.googlesource.com/111100
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Bug: skia:7263
Change-Id: I90fcc35e8d070b324287139ebecc3d15dbec0137
Reviewed-on: https://skia-review.googlesource.com/109164
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This reverts commit 934c3d0c54.
Reason for revert: Chrome
Original change's description:
> Revert "Revert "Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)""
>
> This reverts commit 84d823a5e2.
>
> Reason for revert: The DFT diffs don't repro on Windows so I'm chalking it up to minor device differences
>
> Original change's description:
> > Revert "Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)"
> >
> > This reverts commit 96165ebeaa.
> >
> > Reason for revert: DFT GMs w/ LCD text are slightly different
> >
> > Original change's description:
> > > Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)
> > >
> > > This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
> > >
> > > For the GrDrawOpAtlas:
> > > At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
> > >
> > > The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
> > >
> > > GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
> > >
> > > During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
> > >
> > > The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> > > It now carries a GrProxyProvider for when it needs to create an atlas
> > > It passes in a GrResourceProvider* at flush time to allow instantiation.
> > >
> > > It does not, yet, allocate that GrDrawOpAtlases it might ever require.
> > >
> > > Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
> > > Reviewed-on: https://skia-review.googlesource.com/109749
> > > Reviewed-by: Jim Van Verth <jvanverth@google.com>
> > > Commit-Queue: Robert Phillips <robertphillips@google.com>
> >
> > TBR=jvanverth@google.com,robertphillips@google.com
> >
> > Change-Id: I62efc61c8394477e54d6e79fa2f65180c91a4515
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://skia-review.googlesource.com/110220
> > Reviewed-by: Robert Phillips <robertphillips@google.com>
> > Commit-Queue: Robert Phillips <robertphillips@google.com>
>
> TBR=jvanverth@google.com,robertphillips@google.com
>
> Change-Id: I7c87b4523f9b53285f0de5c2d741a25893522d9a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/110221
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,robertphillips@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I7dd73ab0159f38595f21b21eef3becc10aa0934d
Reviewed-on: https://skia-review.googlesource.com/111080
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 84d823a5e2.
Reason for revert: The DFT diffs don't repro on Windows so I'm chalking it up to minor device differences
Original change's description:
> Revert "Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)"
>
> This reverts commit 96165ebeaa.
>
> Reason for revert: DFT GMs w/ LCD text are slightly different
>
> Original change's description:
> > Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)
> >
> > This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
> >
> > For the GrDrawOpAtlas:
> > At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
> >
> > The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
> >
> > GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
> >
> > During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
> >
> > The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> > It now carries a GrProxyProvider for when it needs to create an atlas
> > It passes in a GrResourceProvider* at flush time to allow instantiation.
> >
> > It does not, yet, allocate that GrDrawOpAtlases it might ever require.
> >
> > Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
> > Reviewed-on: https://skia-review.googlesource.com/109749
> > Reviewed-by: Jim Van Verth <jvanverth@google.com>
> > Commit-Queue: Robert Phillips <robertphillips@google.com>
>
> TBR=jvanverth@google.com,robertphillips@google.com
>
> Change-Id: I62efc61c8394477e54d6e79fa2f65180c91a4515
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/110220
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,robertphillips@google.com
Change-Id: I7c87b4523f9b53285f0de5c2d741a25893522d9a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/110221
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 96165ebeaa.
Reason for revert: DFT GMs w/ LCD text are slightly different
Original change's description:
> Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)
>
> This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
>
> For the GrDrawOpAtlas:
> At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
>
> The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
>
> GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
>
> During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
>
> The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> It now carries a GrProxyProvider for when it needs to create an atlas
> It passes in a GrResourceProvider* at flush time to allow instantiation.
>
> It does not, yet, allocate that GrDrawOpAtlases it might ever require.
>
> Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
> Reviewed-on: https://skia-review.googlesource.com/109749
> Reviewed-by: Jim Van Verth <jvanverth@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,robertphillips@google.com
Change-Id: I62efc61c8394477e54d6e79fa2f65180c91a4515
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/110220
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
For the GrDrawOpAtlas:
At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
It now carries a GrProxyProvider for when it needs to create an atlas
It passes in a GrResourceProvider* at flush time to allow instantiation.
It does not, yet, allocate that GrDrawOpAtlases it might ever require.
Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
Reviewed-on: https://skia-review.googlesource.com/109749
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 056c1a821a.
Reason for revert: GM issues
Original change's description:
> Separate creation time & flush time behavior in GrDrawOpAtlas
>
> This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
>
> For the GrDrawOpAtlas:
> At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
>
> The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
>
> GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
>
> During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
>
> The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> It now carries a GrProxyProvider for when it needs to create an atlas
> It passes in a GrResourceProvider* at flush time to allow instantiation.
>
> It does not, yet, allocate that GrDrawOpAtlases it might ever require.
>
> Change-Id: I54909b7a3ba4bec2db5f1218f6a2a3a1636f66d6
> Reviewed-on: https://skia-review.googlesource.com/108520
> Commit-Queue: Robert Phillips <robertphillips@google.com>
> Reviewed-by: Jim Van Verth <jvanverth@google.com>
TBR=jvanverth@google.com,bsalomon@google.com,robertphillips@google.com
Change-Id: I36eafe46209380f533aa84e831d1c9d18844b6be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/109280
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
For the GrDrawOpAtlas:
At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
It now carries a GrProxyProvider for when it needs to create an atlas
It passes in a GrResourceProvider* at flush time to allow instantiation.
It does not, yet, allocate that GrDrawOpAtlases it might ever require.
Change-Id: I54909b7a3ba4bec2db5f1218f6a2a3a1636f66d6
Reviewed-on: https://skia-review.googlesource.com/108520
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This begins the journey towards using different types to refer to CPU data and GPU texture formats. This is one part of removing GrPixelConfig and more directly using GL/VK texture formats
GrColorType represents a particular layout of color/gray/alpha channels in CPU memory. It does not refer to texture formats or sRGB-encoding. It is basically SkColorType specialized to the GPU backend with some formats added and some removed.
Read/WritePixel interfaces use GrColorType to describe the CPU side of the transaction.
There's still a lot of punting to GrPixelConfig in API-specific code. There's a lot more to be done.
Bug: 6718
Bug: 7580
Change-Id: I8d813ae9a4416a06596f22a4b87da02091989718
Reviewed-on: https://skia-review.googlesource.com/107264
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This change also triggered a bunch of side changes thanks to WrappedProxyTest
fixing/improving how we handle wrapped proxies in genernal.
Bug: skia:
Change-Id: I743a458923cff1c2e947627d0e9154a4c808a668
Reviewed-on: https://skia-review.googlesource.com/108102
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Bug: skia:7604
Change-Id: I508bbdc006e1c6edce2006be0c43b037038c876b
Reviewed-on: https://skia-review.googlesource.com/108360
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Bug: oss-fuzz:6126
Change-Id: I8f6865cbbbfbe37acf940cc2d4ae93204ba7168d
Reviewed-on: https://skia-review.googlesource.com/107783
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
