This reverts commit acf17904d6.
Reason for revert: Chrome
Original change's description:
> Fission GrAtlasGlyphCache in two
>
> This CL splits the old GrAtlasGlyphCache into a GrAtlasGlyphCache and an GrAtlasManager.
>
> The GrAtlasManager itself is split into a rather limited base class (GrRestrictedAtlasManager)
> and the all powerful GrAtlasManager. The GrRestrictedAtlasManager is available at op creation
> time and provides access to the proxies backing the atlases. The full GrAtlasManager is
> only available at flush time and allows instantiation of the proxies and uploading to them.
>
> In the DDL world all of the DDL Contexts will receive a GrRestrictedAtlasManager-version of the
> GrAtlasManager in the main thread. This future atlas manager will have had all of its
> GrDrawOpAtlases created (but not instantiated) so there should be no race conditions.
>
> Change-Id: I9967d3a4116af50128f390c5039a712b8cd4db08
> Reviewed-on: https://skia-review.googlesource.com/108001
> 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: I7c760ea1a9f041a310b96d552aa1497ee5902cd8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/111040
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL splits the old GrAtlasGlyphCache into a GrAtlasGlyphCache and an GrAtlasManager.
The GrAtlasManager itself is split into a rather limited base class (GrRestrictedAtlasManager)
and the all powerful GrAtlasManager. The GrRestrictedAtlasManager is available at op creation
time and provides access to the proxies backing the atlases. The full GrAtlasManager is
only available at flush time and allows instantiation of the proxies and uploading to them.
In the DDL world all of the DDL Contexts will receive a GrRestrictedAtlasManager-version of the
GrAtlasManager in the main thread. This future atlas manager will have had all of its
GrDrawOpAtlases created (but not instantiated) so there should be no race conditions.
Change-Id: I9967d3a4116af50128f390c5039a712b8cd4db08
Reviewed-on: https://skia-review.googlesource.com/108001
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@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>
Makes SkAtlasTextRenderer::SDFVertex now has a 3 component position vector.
Change-Id: I7ec1a8068fb84388a82e1748d6e9d02820d55abd
Reviewed-on: https://skia-review.googlesource.com/84202
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This was causing SkAtlasTextTarget:flush() calls beyond the first to skip the uploads of glyphs added to the atlas after the first flush().
Change-Id: I291b88d50629e38914d4b6af21fc25d8a41fbd9d
Reviewed-on: https://skia-review.googlesource.com/77584
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Change-Id: I7f2b03dd965079f801d66b670bdeb1d01bbf0fd6
Reviewed-on: https://skia-review.googlesource.com/76160
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 39631f3df1.
Reason for revert: break google3 rool
Original change's description:
> Add Atlas Text interface for rendering SDF glyphs.
>
> This new API is built upon SDF text atlas code from the GPU backend. Unlike using the GPU
> backend to draw text, this set of interfaces allows the client to render the SDF glyphs. The
> client issues text draws to potentially multiple targets and then the client flushes. The
> client then gets commands from Skia with data to put into a texture atlas and vertices to
> draw that reference the texture. The client is responsible for creating the texture, uploading
> the SDF data to the texture, and drawing the vertices provided by Skia.
>
> Change-Id: Ie9447e19b85f0ce1c2b942e5216c787a74f335d3
> Reviewed-on: https://skia-review.googlesource.com/59360
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,bsalomon@google.com,robertphillips@google.com
Change-Id: I4aad0c99e645b476fd8ba25731f2a10e8802bb25
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/73420
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This new API is built upon SDF text atlas code from the GPU backend. Unlike using the GPU
backend to draw text, this set of interfaces allows the client to render the SDF glyphs. The
client issues text draws to potentially multiple targets and then the client flushes. The
client then gets commands from Skia with data to put into a texture atlas and vertices to
draw that reference the texture. The client is responsible for creating the texture, uploading
the SDF data to the texture, and drawing the vertices provided by Skia.
Change-Id: Ie9447e19b85f0ce1c2b942e5216c787a74f335d3
Reviewed-on: https://skia-review.googlesource.com/59360
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
