This essentially reverts the CL
https://skia-review.googlesource.com/c/skia/+/180375
at this point combining the strike and glyph cache seems like
the wrong direction.
Change-Id: I66a673469fd12869263a3826d6ec6be622b2b9a1
Reviewed-on: https://skia-review.googlesource.com/c/180777
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Just some cleanup.
Bug: skia:8462
Change-Id: Iad1d3111690c1db1c36a495b4badbe9edd4b5555
Reviewed-on: https://skia-review.googlesource.com/c/180740
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is a reland of d6fa45472c
Original change's description:
> ccpr: Rework the path cache to support sporadic flushing
>
> Removes the notion of a stashed atlas that we store from the previous
> flush. Now we just cache every atlas we ever render. Cached atlases
> can either be 16-bit or 8-bit.
>
> The "reuse" and "animation" cases should both behave exactly the same
> as before: Where before we would copy from the stashed atlas to 8-bit
> atlases, we now copy from a cached 16-bit atlas and then invalidate
> it. Where before we would recycle the stashed atlas's backing texture
> object, we now recycle this same texture object from an invalidated
> 16-bit cached atlas.
>
> The main difference is that cases like tiled rendering now work. If
> you draw your whole scene in one flush, you still get one big 16-bit
> cached atlas, just like the "stashed atlas" implementation. But if you
> draw your scene in tiles, you now get lots of little cached 16-bit
> atlases, which can be reused and eventually copied to 8-bit atlases.
>
> Bug: skia:8462
> Change-Id: Ibae65febb948230aaaf1f1361eef9c8f06ebef18
> Reviewed-on: https://skia-review.googlesource.com/c/179991
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
Bug: skia:8462
Change-Id: I2f64b0c37e2cd644a202dfc786366dda5d238391
Reviewed-on: https://skia-review.googlesource.com/c/181450
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Leverage this in ops that use tessellation with per-vertex coverage, to
move the (color * coverage) work into the vertex shader.
For the tessellating path renderer, color is always uniform, but we were
sending it per-vertex. Added support to the default GP for routing the
uniform color to the vertex shader (when there is per-vertex coverage and
coverage can be folded into alpha). The end result is that we do less work
on the CPU, and send less data (for incompatible blend modes) or the same
amount (for compatible blend modes).
Finally, because color is never sent through a vertex attribute, this
solves wide color (and avoids the vertex bloat that would have happened
when using half-floats). For the linearizing convex path renderer, do the
usual fix for wide color.
PS6 is the "clean" version of this CL, later versions are guarded to
rebaseline layout tests.
Bug: skia:
Change-Id: I7fa87219177d36db800463d4492b78f2cb14a1c3
Reviewed-on: https://skia-review.googlesource.com/c/179996
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Wuffs ships as a "single file C library". Previously, that single file
was a .h file. Now it is a .c file.
The contents of the file are practically the same. The different file
name extension means that the build system (GN/ninja) will treat that
file as a .c file, or "something that generates code", and not merely a
.h file, or "something #include'd by things that generate code".
This should hopefully fix mysterious linker errors when updating the
third_party/wuffs checkout results in the builder doing no work, since
no .c files changed.
Bug: skia:8235
Change-Id: I451e251d8cd23f3f0db359bbe03caa429c00fcea
Reviewed-on: https://skia-review.googlesource.com/c/180420
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Moved named common transfer functions and gamuts to constexpr values in
SkColorSpace.h, in SkNamedTransferFn and SkNamedGamut namespaces.
Converted nearly all SkColorSpace::MakeRGB calls within Skia to use the
new factory with the named values. Multiple clients want a way to
extract named transfer function and gamut - this still doesn't provide
that, but this may be a better path forward for honestly advertising how
SkColorSpace works internally.
Originally landed as:
https://skia.googlesource.com/skia/+/a9549ab31630fc244094e6f1692371cbaf87f666
Re-landing with a new serialization format, but maintaining ability to
load old serialized color spaces, for SKP compatibility.
Bug: skia:
Change-Id: Ib84a6e1cd5d7d9816175773fdbaff2ca32658667
Reviewed-on: https://skia-review.googlesource.com/c/181176
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Seperate concerns so that cache lookup and run setup are different code.
This will allow the common code in painter to do the caache lookup.
Change-Id: I30a208ebc715c07f5720a7a8fc8240aabfda869d
Reviewed-on: https://skia-review.googlesource.com/c/180928
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit d6fa45472c.
Reason for revert: Assertion failures
Original change's description:
> ccpr: Rework the path cache to support sporadic flushing
>
> Removes the notion of a stashed atlas that we store from the previous
> flush. Now we just cache every atlas we ever render. Cached atlases
> can either be 16-bit or 8-bit.
>
> The "reuse" and "animation" cases should both behave exactly the same
> as before: Where before we would copy from the stashed atlas to 8-bit
> atlases, we now copy from a cached 16-bit atlas and then invalidate
> it. Where before we would recycle the stashed atlas's backing texture
> object, we now recycle this same texture object from an invalidated
> 16-bit cached atlas.
>
> The main difference is that cases like tiled rendering now work. If
> you draw your whole scene in one flush, you still get one big 16-bit
> cached atlas, just like the "stashed atlas" implementation. But if you
> draw your scene in tiles, you now get lots of little cached 16-bit
> atlases, which can be reused and eventually copied to 8-bit atlases.
>
> Bug: skia:8462
> Change-Id: Ibae65febb948230aaaf1f1361eef9c8f06ebef18
> Reviewed-on: https://skia-review.googlesource.com/c/179991
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,csmartdalton@google.com
Change-Id: Iad74a14fcb09da12f32b9b78f803b8472a5d60ae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:8462
Reviewed-on: https://skia-review.googlesource.com/c/181444
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Removes the notion of a stashed atlas that we store from the previous
flush. Now we just cache every atlas we ever render. Cached atlases
can either be 16-bit or 8-bit.
The "reuse" and "animation" cases should both behave exactly the same
as before: Where before we would copy from the stashed atlas to 8-bit
atlases, we now copy from a cached 16-bit atlas and then invalidate
it. Where before we would recycle the stashed atlas's backing texture
object, we now recycle this same texture object from an invalidated
16-bit cached atlas.
The main difference is that cases like tiled rendering now work. If
you draw your whole scene in one flush, you still get one big 16-bit
cached atlas, just like the "stashed atlas" implementation. But if you
draw your scene in tiles, you now get lots of little cached 16-bit
atlases, which can be reused and eventually copied to 8-bit atlases.
Bug: skia:8462
Change-Id: Ibae65febb948230aaaf1f1361eef9c8f06ebef18
Reviewed-on: https://skia-review.googlesource.com/c/179991
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
When parsing numbers with long decimals, the fast-path decimal factor
may collapse to zero. Catch this condition (and defer to the slow parse
path).
Bug: skia:8499
Change-Id: I4e364402aecdcca9558d027a55ff297170e2a195
Reviewed-on: https://skia-review.googlesource.com/c/181179
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This is slightly preemptive, since paint still has getters/setters for
these fields, but skia no longer looks at them, so...
Reduces serial size by 20-bytes + size of a typeface
Bug: skia:2664
Change-Id: If1997c823db5b3d83b04cb7e1bc1d6787795b70a
Reviewed-on: https://skia-review.googlesource.com/c/181174
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
* add reset(const SkDescriptor&) to SkAutoDescriptor
* move impl to .cpp
* general updating of code
Change-Id: Id224d73456576927f78b4ba3afecc759c1fe3a1b
Reviewed-on: https://skia-review.googlesource.com/c/181175
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit a9549ab316.
Reason for revert: SKPs changed?
Original change's description:
> Add SkColorSpace factory from 3x3 row-major gamut and transfer function
>
> Moved named common transfer functions and gamuts to constexpr values in
> SkColorSpace.h, in SkNamedTransferFn and SkNamedGamut namespaces.
>
> Converted nearly all SkColorSpace::MakeRGB calls within Skia to use the
> new factory with the named values. Multiple clients want a way to
> extract named transfer function and gamut - this still doesn't provide
> that, but this may be a better path forward for honestly advertising how
> SkColorSpace works internally.
>
> Bug: skia:
> Change-Id: I9296d67e8f0dab5ceb49869cb3ba24e98a05f3c4
> Reviewed-on: https://skia-review.googlesource.com/c/180360
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,brianosman@google.com,reed@google.com
Change-Id: Ie888f877b3c1dba33e1a8c0f5fa92594628de7fb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/c/181300
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 5820b0c3f3.
Reason for revert: Unanticipated gold image differences and performance regressions
Original change's description:
> Use specialized quad lists in rectangle ops
>
> Hopefully reduces memory footprint of GrFillRectOp and GrTextureOp
>
> The original rect code (GrAAFillRectOp) stored 2 SkMatrices (18 floats), 2
> SkRects (8 floats) an SkPMColor4f (4 floats) and a flag (1 int) for a total
> of 124 bytes per quad that was stored in the op.
>
> The first pass at the rectangle consolidation switched to storing device and
> local quads as GrPerspQuads (32 floats), an SkPMColor4f (4 floats) and a flag
> (1 int) for a total of 148 bytes per quad. After landing, several memory
> regressions appeared in Chrome and our perf monitor.
>
> Several intertwined approaches are taken here. First, GrPerspQuad no longer
> caches 1/w, which makes a quad 12 floats instead of 16. Second, a specialized
> list type is defined that allows storing the x, y, and extra metadata together
> for quads, but keeps the w components separate. When the quad type isn't
> perspective, w is not stored at all since it is implicitly 1 and can be
> reconstituted at tessellation time. This brings the total per quad to either
> 84 or 116 bytes, depending on if the op list needs perspective information.
>
> Bug: chromium:915025
> Bug: chromium:917242
> Change-Id: If37ee122847b0c32604bb45dc2a1326b544f9cf6
> Reviewed-on: https://skia-review.googlesource.com/c/180644
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=robertphillips@google.com,csmartdalton@google.com,michaelludwig@google.com
Change-Id: I6067b6c0e103d08787626a0a8eff753a0f0c97b6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:915025, chromium:917242
Reviewed-on: https://skia-review.googlesource.com/c/181167
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Moved named common transfer functions and gamuts to constexpr values in
SkColorSpace.h, in SkNamedTransferFn and SkNamedGamut namespaces.
Converted nearly all SkColorSpace::MakeRGB calls within Skia to use the
new factory with the named values. Multiple clients want a way to
extract named transfer function and gamut - this still doesn't provide
that, but this may be a better path forward for honestly advertising how
SkColorSpace works internally.
Bug: skia:
Change-Id: I9296d67e8f0dab5ceb49869cb3ba24e98a05f3c4
Reviewed-on: https://skia-review.googlesource.com/c/180360
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The cloud-build is now at a new enough Clang to find these.
Bug: skia:
Change-Id: Ib7cfecb7d79194dcdeca7c0cf22a9b2dbb8cb655
Reviewed-on: https://skia-review.googlesource.com/c/181162
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Joe Gregorio <jcgregorio@google.com>
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Rearranges the code to support the case "&key == &proxy->fUniqueKey".
Removes the redundant GrUniqueKey parameter from
GrProxyProvider::removeUniqueKeyFromProxy (we can just get the key
from the proxy itself). Adds a passthru for "processInvalidUniqueKey"
to GrOnFlushResourceProvier.
Bug: skia:8462
Change-Id: I0c1e1f2c6ff15a9976f8475c19fd8a33a363193c
Reviewed-on: https://skia-review.googlesource.com/c/180048
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Hopefully reduces memory footprint of GrFillRectOp and GrTextureOp
The original rect code (GrAAFillRectOp) stored 2 SkMatrices (18 floats), 2
SkRects (8 floats) an SkPMColor4f (4 floats) and a flag (1 int) for a total
of 124 bytes per quad that was stored in the op.
The first pass at the rectangle consolidation switched to storing device and
local quads as GrPerspQuads (32 floats), an SkPMColor4f (4 floats) and a flag
(1 int) for a total of 148 bytes per quad. After landing, several memory
regressions appeared in Chrome and our perf monitor.
Several intertwined approaches are taken here. First, GrPerspQuad no longer
caches 1/w, which makes a quad 12 floats instead of 16. Second, a specialized
list type is defined that allows storing the x, y, and extra metadata together
for quads, but keeps the w components separate. When the quad type isn't
perspective, w is not stored at all since it is implicitly 1 and can be
reconstituted at tessellation time. This brings the total per quad to either
84 or 116 bytes, depending on if the op list needs perspective information.
Bug: chromium:915025
Bug: chromium:917242
Change-Id: If37ee122847b0c32604bb45dc2a1326b544f9cf6
Reviewed-on: https://skia-review.googlesource.com/c/180644
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Bug: skia:
Change-Id: Icb840daf1fd31afdeed387486db54283bb5b85f3
Reviewed-on: https://skia-review.googlesource.com/c/180640
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This was a pretty serious performance regression, especially on ARM.
Code size was wash, almost exactly 1:1.
While I like this one-big-switch approach in terms of maintainability
and platform obliviousness, I'm not willing to take such a big hit.
This'll just have to stay platform-aware.
(The old code is also easier to debug and profile, but that's peanuts.)
https://perf.skia.org/e/?begin=1546440652&end=1546459404&keys=X2ec5a42b0071f8848a5875f14400493d&xbaroffset=39028
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: Ia47fd25bbe4145468efd67cbddef7e6f92de3f02
Reviewed-on: https://skia-review.googlesource.com/c/180940
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Since we only see glyphs now, we don't need to treat text runs generically
with an encoding.
Bug: skia:
Change-Id: I683d00772bca96973a1cbd65145b46ffc741418b
Reviewed-on: https://skia-review.googlesource.com/c/180921
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Reed <reed@google.com>
We want to hide this API from general public use. Chromium can dig into
skia to include it as it does with other Skia API's that are in src
Bug: skia:
Change-Id: I00dc36d181237ea0785eefb31ad6c2d4e50e3c68
Reviewed-on: https://skia-review.googlesource.com/c/180648
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
- avoid using legacy paint->font converter
- call out that drawText exists just for testing
- simplify drawText to assume UTF8
Bug: skia:
Change-Id: Ide14d8581d4744827d2282e7983cc5e19070b21e
Reviewed-on: https://skia-review.googlesource.com/c/180641
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This sets up the context and adds support for creating RTContexts, RTProxies, RTs,
and GrVkRenderPass's that wrap the external secondary command buffer.
Bug: skia:
Change-Id: I80ebbb690a5fe464f775c5fcad651dfe2a150418
Reviewed-on: https://skia-review.googlesource.com/c/178926
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
1) Almost nothing is ever DCI P3, cameras and such use Display P3
2) This transfer function was wrong: DCI P3's TF is gamma 2.6
Bug: skia:6720
Change-Id: I167a3ce40ff2296f4afb446408f691d300dacd9c
Reviewed-on: https://skia-review.googlesource.com/c/180378
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is the first step of making a wrapper class to keep these two caches
in sync.
Change-Id: I84ef408a31a77074191a60c8b5943ededcd306b7
Reviewed-on: https://skia-review.googlesource.com/c/180375
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: Ic2e6259345b3b25075f0a5eb52bfc8df272a2de3
Reviewed-on: https://skia-review.googlesource.com/c/180601
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Doing some comparative bench runs, I think allocating a little space
here on the stack looks important.
I do want to see if we can get away with this simpler SkSTArray pair
setup instead of the old approach, building a linked list in reverse
inside an SkAlloc. I'm going to try that old approach too for
comparison, but if there's no big difference I like this way.
Change-Id: I01486d8d8c90e159d22659b5bc678ecce6241618
Reviewed-on: https://skia-review.googlesource.com/c/180603
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This would toss the _obs mode SkRasterPipelines into highp way too often, and is just a bug.
This fixes most diffs between the jumper and obs modes. The rest look like FMA changes, and there are no diffs when limited to SSE4.1.
Change-Id: Ib71c2a8c720b8b1e6319d1c3354ea6f4f2d9b77f
Reviewed-on: https://skia-review.googlesource.com/c/180602
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit d7c2a383e1.
Reason for revert: Attempting re-land.
Original change's description:
> Revert "Wide color support in AA Convex path renderer"
>
> This reverts commit 51eaa79d19.
>
> Reason for revert: Speculative revert for layout tests.
>
> Original change's description:
> > Wide color support in AA Convex path renderer
> >
> > Fixes several more GMs in glenarrow
> >
> > Bug: skia:
> > Change-Id: I3446101e8fd56bb7173cd640a9ccf32b4951842a
> > Reviewed-on: https://skia-review.googlesource.com/c/179990
> > Reviewed-by: Mike Klein <mtklein@google.com>
> > Commit-Queue: Brian Osman <brianosman@google.com>
>
> TBR=mtklein@google.com,brianosman@google.com,csmartdalton@google.com
>
> Change-Id: I9990ec3cfdf35ce870b8205b6317d7787a02d7c7
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:
> Reviewed-on: https://skia-review.googlesource.com/c/180321
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,brianosman@google.com,csmartdalton@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: skia:
Change-Id: I1b6733e6307f917e8945454140c4acee96b33c7f
Reviewed-on: https://skia-review.googlesource.com/c/180366
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
