Bug: skia:7769
Change-Id: Ida462aec8ad832f01aec07602d8be5735a9b0ca2
Reviewed-on: https://skia-review.googlesource.com/118582
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Bug: skia:7769
Change-Id: Ibf52ebfe5bb79afd0358278fbd284084a10b076b
Reviewed-on: https://skia-review.googlesource.com/118180
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Currently we try to get Helvetica or the default font and draw a pipe
and look to see if there is any non-gray. We should bring our own font
for this check, since sometimes the system font may not be accessible.
BUG=chromium:822218
Change-Id: I9c4988b0acbb5a59445a0ec7f3fade73678b973e
Reviewed-on: https://skia-review.googlesource.com/117862
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Same change as the 1D one, but now with more dimensions!!
Bug: skia:7769
Change-Id: I152031780ab71ba106d4fa65d52960ec4358274e
Reviewed-on: https://skia-review.googlesource.com/118262
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:7769
Change-Id: I56a67f8a6f19437359ad6e7bf2d57f6e9a7992c9
Reviewed-on: https://skia-review.googlesource.com/118240
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
throw an error instead of asserting for one
for the other, only assert if the values are trusted. That's not ideal,
but I don't see an easy way to insert a fail safety hatch in this code
and if the assert is ignored, no further assert is triggered.
verified that extended tests run without problem on debug and release
R=kjlubick@google.com
Bug: skia:
Change-Id: I5544b6cbef97479854dbecb05baae6b2c41cabc9
Reviewed-on: https://skia-review.googlesource.com/117725
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
stroke -> Inf -> NaN -> assert.
BUG=skia:7775
Change-Id: I086883bce90d1d473cff87f67e954718ea3181f6
Reviewed-on: https://skia-review.googlesource.com/118145
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Allows ApplyGammaTest to pass on Bifrost, which uses fp16 for mediump.
Change-Id: Icd04001939a2cb7e1789132ab035ca498c92112a
Reviewed-on: https://skia-review.googlesource.com/118162
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Performs inset and outset operations on simple polygons and returns
a simple polygon, if possible.
Bug: skia:
Change-Id: I6d468174ad70b5279b736c532e19cbb84ff9f955
Reviewed-on: https://skia-review.googlesource.com/116483
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Not sure whether this will fix b/77249109, but we can have a try.
Bug: b/77249109
Change-Id: Ia569cb130758dd0a63bfe2ecb29e61c75716c955
Reviewed-on: https://skia-review.googlesource.com/117460
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Before this change SkScalerContext::getMetrics always calls
generateMetrics to force the subclass to create full metrics. However,
if the SkScalerContext is going to draw from outlines then there is no
reason to do so since it is immediately going to overwrite those metrics
by computing its own from the path. This also puts off other decisions
being made based on the glyph metrics until after the metrics are fully
computed.
The logic in SkScalerContext::getImage is updated to be similar to the
logic in the new SkScalerContext::getMetrics.
Change-Id: I1798c9244277fab85595fb39fc3a85ef7eb33620
Reviewed-on: https://skia-review.googlesource.com/117085
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@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>
Also, clean up Freetype and Mac impls.
Also, sk_get_locale_string returns an error value.
Change-Id: If8dfc101e28a1d782679174fe6f5a28812563af5
Reviewed-on: https://skia-review.googlesource.com/117229
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
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>
Unlike the specVersion parameter on the layers, specVersion on extensions
does not mean what vulkan spec version the extensions work with but just
what version of the extension it is. Thus we don't want to compare it
to the version of the spec we are making.
Bug: skia:
Change-Id: If47c249b4cca0b9a10bfb3b8ce88db6bda1e12ed
Reviewed-on: https://skia-review.googlesource.com/117634
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
fuzzer bug triggers an assert in SkRRect::isValid because
on radius is zero and the other, while small, is not.
The radii are normally both set to zero if one is zero
in SkRRect::setRectRadii. However, subsequently scaleRadii
may set one to zero when normalizing the pair.
Move the clamping code out of setRectRadii so it can be
called from scaleRadii as well.
R=reed@google.com
Bug: skia:
Change-Id: Ib9a86da7212567b2f4b83d99a41cf9ba2c30e9b9
Reviewed-on: https://skia-review.googlesource.com/115701
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
This reverts commit a466228a61.
Reason for revert: Turned up a vulkan driver bug
Original change's description:
> Delete GPU alpha clip masks
>
> The cost of switching render targets on each draw to make a custom
> clip is enormous. There are virtually no circumstances where this will
> outperform our cached, multi-threaded software mask generator. The
> tried-and-true approach to clipping on-GPU is with analytic FPs. And
> now that we support CCPR clip FPs, there ulitmately should be very few
> clip stacks that even require a mask as long as they don't use
> deprecated SkClipOps.
>
> Bug: skia:
> Change-Id: I79c5558c93c1b99179f1e933d029f69b14ad1ce3
> Reviewed-on: https://skia-review.googlesource.com/116724
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
TBR=robertphillips@google.com,brianosman@google.com,csmartdalton@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: skia:
Change-Id: Iba289e00ba2eca7084dc8517491cfb5f6ab6266f
Reviewed-on: https://skia-review.googlesource.com/117420
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
GpuResources now dump optional string values that describe the type and
category of the resource. The type provides a description of the kind
of resource it is (e.g. texture, buffer object, stencil, etc.) and the
category describes what the resource is currently tasked to do (e.g.
path masks, images, scratch, etc.)
This CL also refactors the dump logic in an attempt to consolidate
duplicated code into GrGpuResources.cpp.
Bug: b/74435803
Change-Id: I83cae825f41e6450a21398ab3ecea349c7c61c15
Reviewed-on: https://skia-review.googlesource.com/115989
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
These appear to have been added to handle glyph paths with nvpr and no
longer appear to be used.
Change-Id: Id75e2e85ab837a5808e7641873d217c844cd827c
Reviewed-on: https://skia-review.googlesource.com/117103
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This is a reland of 050c86768a
Original change's description:
> GrTessellator: hang fix.
>
> Some edges are not coincident with their own endpoints (because floating
> point). If this happens for an edge which is a right-enclosing-edge
> during the Bentley-Ottman simplify() pass, we end up an infinite loop
> attempting to split the edge, since the edge is never to the right of its
> endpoint.
>
> The easiest fix is to simply remove the right-enclosing-edge splitting
> code. This code was originally added before we had proper
> active-edge-list rewinding, and should no longer be necessary.
>
> BUG=802896
>
> Change-Id: Id9f2942b73f01152af8c0088e8c6b1389891d827
> Reviewed-on: https://skia-review.googlesource.com/116920
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
Bug: 802896
Change-Id: I3e48346a8a358ae7d481299a586003e817a519ca
Reviewed-on: https://skia-review.googlesource.com/117121
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Id7238e427e490338d1f610255774c2069cfd4879
Reviewed-on: https://skia-review.googlesource.com/117060
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
