This makes part of of our testing infrastructure (i.e., the GMs)
compatible with Graphite's more stringent requirements.
Bug: skia:12701
Change-Id: I5d2bf44a1f044797971a1cf6874cf1819d715ca6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530539
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit a370ecf9fc.
Reason for revert: This broke iOS and Mac bots
Original change's description:
> [infra] Update iOS device provisioning profile.
>
> We're moving from Apple's Enterprise program to their Developer program,
> which requires a new profile. Versions 7 and 8 were mistaken uploads of
> who-knows-what by yours truly, so we skip them.
>
> Change-Id: I1b7913781eae5c643e60b47ad374a4365cef7bce
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531553
> Reviewed-by: Ravi Mistry <rmistry@google.com>
> Commit-Queue: Erik Rose <erikrose@google.com>
Change-Id: Icbf9fbf6ed1b84a884ed6aeeebe37ea04ad14bb2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531696
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: George Wright <wrightgeorge@google.com>
We're moving from Apple's Enterprise program to their Developer program,
which requires a new profile. Versions 7 and 8 were mistaken uploads of
who-knows-what by yours truly, so we skip them.
Change-Id: I1b7913781eae5c643e60b47ad374a4365cef7bce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531553
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Erik Rose <erikrose@google.com>
(This mirrors an optimization performed in the constant folder.)
Expressions like `OpIEqual %20 %20` or `OpFUnordNotEqual %15 %15` can be
replaced by `true` or `false` on sight. The GLSL spec makes it clear
that checking for NaN is optional:
4.7.1 Range and Precision
"... NaNs are not required to be generated. Support for signaling NaNs
is not required and exceptions are never raised. Operations and built-in
functions that operate on a NaN are not required to return a NaN as the
result."
Change-Id: I2e29b659a73582e9ade0eb61f70f7d362a007c50
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531550
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, every expression/statement type was responsible for
pruning or clearing the store-cache when branches were involved. This
was difficult to reason about and easy to get wrong, particularly if
the details are not fresh in your mind.
Now, `writeLabel` takes care of the details for you. Pass in the
location of the branch(es) which use the label, and the proper cache
updating behavior will occur automatically.
Some of the label enum types are not strictly necessary and exist for
the benefit of a reader. Specifically:
- `kBranchlessBlock` and `kBranchIsOnPreviousLine` are synonyms
- `kBranchIsBelow` and `kBranchesOnBothSides` are also synonyms
The hope is that extra enum names will be easier for a reader to
follow, versus fewer but very-verbose enum names (like
`kBranchIsBelowOrOnBothSides`).
This change earned some very minor switch-related dividends. Previously,
every label in a switch was treated as a forward-branch, but in fact,
the very first label in a switch is privileged. This is because we are
branching from the previous line, and the store cache is trustworthy in
this case. (Versus "branching from above," where the store cache needs
to be pruned before it can be trusted.)
Change-Id: I38b539069c22be9f0777b632f60f0eab2409d687
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531540
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit f33cf451a2.
Reason for revert: breaking the android roller
Original change's description:
> Update VMA to latest version.
>
> This is needed so that we can use non skia supplied vk_mem_alloc.h on
> clients that have already updated to newest version. As we transition
> to Bazel builds this helps to make it so we can set the rules for
> specific clients around VMA without things breaking
>
> Bug: skia:13211
> Change-Id: I5d38a3a91a44f6b3fdf75894a3248ee3991dd5d9
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531157
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
Bug: skia:13211
Change-Id: Ibd621aa2f07359f9b72e1a35df0f50ca3c063e86
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531543
Auto-Submit: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Now that we can call into Skia utils directly, we can use the
preexisting code from SkOSPath instead.
Change-Id: I67e3099e97ec0e93acc08c7f2142a01a2af48f15
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531416
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
FreeType introduced FT_LOAD_COLOR in 2.5 so an application could
indicate that it could handle the new color format. If this glyph load
flag was not set then the colors would be desaturated into the old gray
format so that something would be drawn while applications were updated.
The only source of color glyphs was bitmaps, but Skia always set the
flag on both scalable and non-scalable (bitmap and outline) fonts.
In FreeType 2.10 the meaning of this flag was expanded to mean that
using FreeType to render a glyph with an associated COLR entry would
attempt to draw using the color layers instead of the base glyph. This
did not affect Skia since Skia handles the color layers itself.
In FreeType 2.12 the meaning of this flag was updated again to mean that
if using FreeType to load a glyph with an associated SVG entry would
prefer loading the glyph with a new FT_GLYPH_FORMAT_SVG. This means any
users loading a glyph with FT_LOAD_COLOR on a scalable font (like Skia
has been) will get this new format and not the base outlines.
In order to work properly with this setup, Skia must ensure the
FT_LOAD_COLOR is only set on scalable (outline) fonts when Skia supports
SVG glyphs. For now this means setting FT_LOAD_COLOR on bitmap fonts
only with a comment where it should be set when SVG is supported.
Change-Id: Iaf8991b73d353ab7bda836ff4c290d75ab519d78
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531323
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This is needed so that we can use non skia supplied vk_mem_alloc.h on
clients that have already updated to newest version. As we transition
to Bazel builds this helps to make it so we can set the rules for
specific clients around VMA without things breaking
Bug: skia:13211
Change-Id: I5d38a3a91a44f6b3fdf75894a3248ee3991dd5d9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531157
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This is a reland of commit ca0c82a968
Original change's description:
> Eval args of trace macros in debug builds
>
> Change-Id: I9ae48cfa23948fbdcdf6e8997365f5a8c2b3be8b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530677
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Change-Id: I8eb6c5fb129e907577c504776c3bab37c6a94fec
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531236
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Have the GrAtlasManger handle the logic of the
fSupportBilerpFromGlyphAtlas flag directly. This dramatically
reduces the complex plumbing the current code uses.
This is part of a larger CL that has a crash on MSVC-Direct3d-Release
bot, but not the debug bot. I'm breaking the CL into very small
pieces to find the problem.
Change-Id: Idbad1614b511041893c00c291c9db1cf61ab5532
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530737
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I28ef42ff417faf98eb1f124d4a1987b6cc4a609f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530456
Auto-Submit: Eric Boren <borenet@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
These were from a previous attempt.
Change-Id: Ia057e5e23d2ba97e33f1bb7fafc785a3ee92d66e
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531096
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
We now have two functions `writeOpLoad` and `writeOpStore` which are
in charge of writing SpvOpLoad and SpvOpStore instructions.
`writeOpStore` also keeps track of pointer stores in a "store cache."
Subsequent loads from that same pointer will be found in the cache and
will return the value stored in that pointer instead.
Such a cache definitely cannot work in the face of control flow, so we
make the following concessions:
- `pruneReachableOps` is now `pruneConditionalOps`. Any pointers that
are altered inside a potentially-unreachable block are cleared from
the cache entirely.
- The entire store cache is cleared at all OpLabels within a loop.
The cache also cannot work in the presence of swizzled stores, so we
make another significant concession:
- The entire store cache is cleared whenever we store into a non-memory
pointer (e.g., assigning into a swizzled LValue, such as `foo.xz`).
Despite these significant limitations, this manages to dramatically
shrink many real-world examples.
Change-Id: I0981a0cf7b45b064e153e9ada271494c8e00cad5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530054
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Graphite won't draw non-Graphite-backed images so we need to update our
tools to meet that requirement.
Bug: skia:12701
Change-Id: I66dc371b2e11e327e1d371115fb62c85863308e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530542
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This just adds texture coordinate normalization and kClamp and kRepeat
support.
Bug: skia:12701
Change-Id: I17ed0ccfd95d7081a77cb23428a14f6fef0a118b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530538
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: I9ae48cfa23948fbdcdf6e8997365f5a8c2b3be8b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530677
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Some of our oss-fuzz tests contain garbage data which isn't in any
encoding. This throws an error unless the files are opened in binary
mode.
Change-Id: I5caf307f3c79fba5b177496fd8ced8381205b97e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530679
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
It is possible for a single glyph to have multiple representations. In a
COLRv0 or COLRv1 font the outlines of the sub glyphs must be used as
layers or clips. Ensure that bitmaps and SVG representations are
explicitly excluded when loading glyphs with the express purpose of
retrieving any available outline.
Note that this does not touch the flags used in generatePath because in
that case a path should only be loaded if the glyph representation for
rendering is actually outline based.
Change-Id: I499e23aa20dacead81c7f76980039f139fa8edce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530676
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Now that getType no longer needs it, this was only used to see if two
types matched (modulo precision).
Change-Id: Icdf507573f03a8caf2b202465a83e50359eb6446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530570
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
Previously, we would determine the operandType by calling
`getActualType`. This function converts half-precision types to full-
precision ones, which seems to have been unintentional. Fortunately, the
operand type is not actually emitted into the SPIR-V by most code paths
(most paths use the resultType instead) so it was not a significant
impact in practice. A few matrix-based paths emitted ops using this type
and these paths now emit RelaxedPrecision as expected.
Change-Id: I32f4c0327427476fee6b78953284818b7970b6e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530543
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
This now uses existing logic from `nextId` rather than reinventing the
wheel.
Change-Id: I2879fa42e8df6d70936ce7e322d48e4990d79319
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530540
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
The COLRv1 bounding box is currently computed without the subpixel
offset. This can lead to cropping of a row or column at the edge of the
rendering. Apply the subpixel offset to the base bounding boxes.
This is simplified by always converting the FT_BBox to an SkRect as
early as is convenient and unifying the COLRv1, COLRv0, outline, and
bitmap application of subpixel positioning and conversion of bounds to
glyph bounds.
This also fixes a long standing issue where it is possible for subpixel
positioned empty (space) glyphs to have non-zero bounds since rounding
out a non-integer aligned empty SkRect to an SkIRect will produce a unit
SkIRect.
Change-Id: I634783250942d0cd45cf28e81d5fd695982547cf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530523
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
SkFindQuadMaxCurvature returns either a value in [0, 1) or NaN.
split_conic uses this to determine where to chop a conic, but doesn't
check for NaN, and passing NaN to conic.chopAt() will assert. Inverting
the if statement and checking to see if t is in (0,1) rather than that
t == 0 || t == 1 will cover the NaN case, since NaN comparisons are
always false.
Bug: skia:1310167
Change-Id: I401f586d9b4cb9f05332027627f9fac9dc7dee15
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530519
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
We will need this in a followup, because we can apply optimizations to
function-class LValues that wouldn't make sense for other classes.
Change-Id: I99855961cfb8c5bfac0068e33e20e2e687f5aefe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530537
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:13212
Change-Id: I8fc8bcd01181fcfb9955119984afa4bfbb1f73e5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529756
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
