Our current intent is to disable MSAA for all of Intel, but it snuck
through on Intel.
Change-Id: I1fb5c4d88a9650556f3e64f7a3aaaa3907169c76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442036
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This reverts commit 9155b338bb.
Reason for revert: disable test for GLSL + Adreno 6xx
Original change's description:
> Revert "Add ES3 intrinsics isinf/isnan to public SkSL ES3."
>
> This reverts commit e43714f490.
>
> Reason for revert: Several Pixel (Adreno) devices failing the test
>
> Original change's description:
> > Add ES3 intrinsics isinf/isnan to public SkSL ES3.
> >
> > The ES3 spec doesn't mandate that `isnan` actually has to do anything,
> > so the Isnan test is not enabled. (It doesn't work on my personal
> > machine unless I make the NaN detectable at compile-time.)
> >
> > We do not support these functions in constant-expressions, as we
> > currently avoid optimizing anything into a non-finite value; we leave
> > expressions alone if we calculate a NaN/inf result for their value.
> >
> > Change-Id: Ibfdfb47b6e6134165c8780db570de04a916d2bfa
> > Bug: skia:12022
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441581
> > Auto-Submit: John Stiles <johnstiles@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: John Stiles <johnstiles@google.com>
>
> TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
>
> Change-Id: I89899ed391aa870350d0452bab4a0fb75bd7be38
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:12022
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441716
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12022, skia:12377
Change-Id: Ib149dbc1138feb3ee2bf6f7e31e9e8a9414560bc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441884
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Ia5a11580a793226253e2e294f6c43aa76fa97e8f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441882
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Change-Id: I4a825c0d191f3f24d558c4331e07fe2a55832f76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441838
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
We'll switch to the correct context when necessary (e.g. before
calls that talk to the GPU). This is achieved by adding in
calls at the JS layer to switch the context before making a call
that is known to talk to the GPU (e.g. draw calls on SkCanvas).
Another implementation that was considered was to add a C++
shim in GrGLInterface that would switch the context before
every call in the GPU - however, that seemed too difficult
and would add extra overhead if a single draw* call talks
to the GPU multiple times.
Bug: skia:12255
Change-Id: I96e4c6b41a5bfcc9913aeaca7ccb125358048ad3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432136
Reviewed-by: Brian Salomon <bsalomon@google.com>
We're seeing a significant perf hit when running on Mac msaa8, so
disabling for now.
Bug: skia:12376
Change-Id: Ic785e99b2ae42aeb54f8313114d82202b645b273
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441881
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Our SPIR-V code generator did not implement support for negating a uint.
However, this is something that GLSL allows (as does the rest of SkSL).
I checked glslang and it uses OpSNegate here. The SPIR-V docs indicate
that OpSNegate allows any type of integer, and the validator lets it
pass, so we now use OpSNegate here as well.
http://screen/33mkq92uxAT5Xu8http://screen/4YBTh3gCWz8eZx7http://screen/388HtXyytcN5vLZ
Change-Id: I8c142018fd5e162dcd051abe1bc5d69a6e034794
Bug: oss-fuzz:37627
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441880
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, a struct containing a vardecl with multiple declarations
would interpret arrays incorrectly. An array would be applied to ALL
variables in the decl after its initial appearance. That is,
`int w, x[10], y, z;` would be interpreted as
`int w, x[10], y[10], z[10];`.
This is now fixed and our test case runs as expected.
Change-Id: I5b4a617c58cdfb83face651effd42770a1f68638
Bug: oss-fuzz:37622
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441879
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer detected a serious parsing error; a struct containing a
vardecl with multiple declarations would interpret arrays incorrectly.
An array would be applied to ALL variables in the decl after its initial
appearance. That is, `int w, x[10], y, z;` would be interpreted as
`int w, x[10], y[10], z[10];`. The fuzzer caught this by putting two
arrayed variables in a row; the second variable was interpreted as a
nested array, which led to an assertion.
This CL contains a simple hand-written test case demonstrating the bug,
with the fix coming in a followup.
Change-Id: I42d7372ba77fa1528ae24eb8c29a2e5903784139
Bug: oss-fuzz:37622
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441878
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We weren't coercing the expression because we don't care about its type,
but that allowed intermediate-expressions to pass through without
reporting an error. Now we coerce the expression to its present type,
which will always fail if the type is disallowed and succeed otherwise.
Change-Id: Ic0de0d17f0f5d56360575efe992ce4d74dec2a5a
Bug: oss-fuzz:37620
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441876
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The BuiltinTypes helper functions were deleted as part of
http://review.skia.org/423585, and the friend class is no longer needed.
Change-Id: I9a1980daa1891fc5c3c12dc35a5a1037e64dea86
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441799
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Support is added so we can differentiate between using discardable
msaa for normal msaa draws and using it for DMSAA. Before this
many asserts and checks throughout GrVk* assumed we could only have
discardable msaa if the actual render target was msaa.
After this change the only thing missing to enable DMSAA on Vulkan
is to fix GrProgramInfo to store the actual sample count the program
will use instead of the same count of the GrRenderTarget.
Change-Id: Ifdb9a3beb641f96f6dfebe3241ccc5a2c8770bb3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441517
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
src/gpu/GrBlockAllocator -> src/core/SkBlockAllocator
src/gpu/GrTBlockList -> src/core/SkTBlockList
Tests and references also renamed.
Bug: skia:12330
Change-Id: I5fad05faa3dcecd89a0a478dcf30c090ea7589f5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441477
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This reverts commit e43714f490.
Reason for revert: Several Pixel (Adreno) devices failing the test
Original change's description:
> Add ES3 intrinsics isinf/isnan to public SkSL ES3.
>
> The ES3 spec doesn't mandate that `isnan` actually has to do anything,
> so the Isnan test is not enabled. (It doesn't work on my personal
> machine unless I make the NaN detectable at compile-time.)
>
> We do not support these functions in constant-expressions, as we
> currently avoid optimizing anything into a non-finite value; we leave
> expressions alone if we calculate a NaN/inf result for their value.
>
> Change-Id: Ibfdfb47b6e6134165c8780db570de04a916d2bfa
> Bug: skia:12022
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441581
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I89899ed391aa870350d0452bab4a0fb75bd7be38
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441716
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Use 4 internal msaa samples on mobile and AppleM1, otherwise 8.
Bug: skia:12372
Change-Id: Ic64d93d65d9fef89df08f7471f9552b4a2546316
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441682
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Bug: skia:12302
Change-Id: I8cf958acf9214d0de903a4097647afd74f2a659e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441541
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I429771c977a0f01805ea49077fe8cda642f1a477
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441308
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
The ES3 spec doesn't mandate that `isnan` actually has to do anything,
so the Isnan test is not enabled. (It doesn't work on my personal
machine unless I make the NaN detectable at compile-time.)
We do not support these functions in constant-expressions, as we
currently avoid optimizing anything into a non-finite value; we leave
expressions alone if we calculate a NaN/inf result for their value.
Change-Id: Ibfdfb47b6e6134165c8780db570de04a916d2bfa
Bug: skia:12022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441581
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
If x is a known compile-time constant value, it can already be optimized
to a final value.
If x is not known, it could be zero, and 0/0 should result in a NaN.
Change-Id: I643a7c6da0a43ec366235c4df39fc78d3b361de7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441580
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I26754745aa26313a2f76a86bd41699c7ac5b8a46
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441596
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Deletes SkConservativeClip as a type, it was only used by
SkNoPixelsDevice at this point.
Simplifies the clip tracking to only rely on intersect/difference ops
(but also expands it to support updating overall bounds if the diff
op is a sufficiently large rectangle).
Adds SkRect::roundIn() -> SkIRect to match the exposed API for round()
and roundOut().
Bug: skia:10205
Change-Id: I1337a51a8a4e51f94fe2b5f9ab29a0b5058b8094
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437737
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
After further discussion, using intrinsics with signatures similar to
sample keeps us looking like GLSL. However, using "sample" is still
misleading, so this adds explicit "shade", "filter", and "blend"
intrinsics. After migrating clients, the "sample" versions will be
removed.
Bug: skia:12302
Change-Id: Ia03e4b3794fc1fc5ae3c3099a7a350343ec7702e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441457
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
The additional tests from http://review.skia.org/441238 uncovered a gap
in the constant folder's abilities; it was not able to fold away
boolean vector comparisons even when they were constant. These are ES2
constant-expressions, so folding them properly is a requirement.
Change-Id: Ia0b4d5d1215c5fc2b247ac3f0dec4c8747d2153e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441579
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We've been cargo-culting these extensions around for a long time, but it
appears they aren't actually necessary.
Change-Id: I536ec9b81643c7d35f108d230233bb6990fcb5d7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441519
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
I've also added a new runtime_intrinsics slide which plots all of the
ES3 section 8.3 intrinsics for testing purposes. We already had SkSL
tests for the ES3 versions of these functions in intrinsics/.
Change-Id: Ie4cec34cacddc26be78dce1e641de8172fcefd99
Bug: skia:12022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441578
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Instead of a series of green dots, we now get a smooth antialiased line.
This is especially useful on high-DPI displays, as previously the green
dots had gaps between them (making the plot appear as a dashed line).
Change-Id: I947e9ec31fafd133a2458bf508102fedd3eaea1a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441577
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit f248b35d75.
Reason for revert: adding guard around aa disabling
Original change's description:
> Revert "Downgrade giant clip ops' AA in SkRasterClipStack"
>
> This reverts commit 3a15110898.
>
> Reason for revert: needs a build flag to roll into g3
>
> Original change's description:
> > Downgrade giant clip ops' AA in SkRasterClipStack
> >
> > Anti-aliased path rendering in the software backend has an internal
> > limit of +/-16384 per coordinate. Path rendering is triggered by draws
> > and clips. Draws are tiled at a high-level before entering the blitter,
> > so this limit will not be encountered. Coverage mask generation for
> > AA clips, however, is not tiled. Normally, it relies on the path being
> > clipped by the underlying device dimensions. When the device itself
> > is larger than 16384, then the clip ops can reach the blitter and
> > exceed the internal limit.
> >
> > When this happens, SkScan::FillPath adds a hard rect clip, which is
> > what caused the mis-applied clip seen in the attached bug report.
> >
> > This CL detects when the canvas/device dimensions are large enough to
> > cause this problem and forcefully disables anti-aliasing for all clips.
> > This shouldn't really be a visual behavior change since the blitter
> > already was downgrading from AA. The main advantage is that the clip
> > stack will use SkRegion for BW clips exclusively instead of switching
> > to use SkAAClip.
> >
> > It was decided to handle this at the clip stack level vs. a per-op
> > decision since a non-AA large clip element used with SkAAClip (
> > triggered by a smaller non-problematic op) would still show the bug.
> >
> > This is only a mitigation. The long-term solution is to use tiling for
> > clipping as well as drawing (possibly by requiring the tiling to be
> > handled by clients, with surface creation failing at sizes > 16k).
> >
> > Bug: chromium:1240718, skia:7998
> > Change-Id: I1f4cae540bec4d44c6e1d8032ded9e95ff32b82f
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441456
> > Reviewed-by: Mike Reed <reed@google.com>
> > Commit-Queue: Michael Ludwig <michaelludwig@google.com>
>
> TBR=reed@google.com,michaelludwig@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
>
> Change-Id: I6008cef5f7df48f27497e2ec75db14584c2acb68
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1240718, skia:7998
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441520
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
# Not skipping CQ checks because this is a reland.
Bug: chromium:1240718, skia:7998
Change-Id: Ie152db8dd95b1f40cbfa26c1c4543601f3f53754
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441497
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Much easier to maintain, especially with an upcoming change to the
sampling syntax.
Change-Id: I378811b7be0afcce5b7e68a942e7b46d96568155
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441518
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
The inliner contained a type error when attempting to inline a function
that takes an array as input. The scratch copy of the array was created
as `float[123] var;` instead of `float var[123];`. This led to an
assertion in VarDeclaration::Make.
Change-Id: I5128fe71462bb59a015a7b4e59c1a74800828b16
Bug: oss-fuzz:37466
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441576
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 3a15110898.
Reason for revert: needs a build flag to roll into g3
Original change's description:
> Downgrade giant clip ops' AA in SkRasterClipStack
>
> Anti-aliased path rendering in the software backend has an internal
> limit of +/-16384 per coordinate. Path rendering is triggered by draws
> and clips. Draws are tiled at a high-level before entering the blitter,
> so this limit will not be encountered. Coverage mask generation for
> AA clips, however, is not tiled. Normally, it relies on the path being
> clipped by the underlying device dimensions. When the device itself
> is larger than 16384, then the clip ops can reach the blitter and
> exceed the internal limit.
>
> When this happens, SkScan::FillPath adds a hard rect clip, which is
> what caused the mis-applied clip seen in the attached bug report.
>
> This CL detects when the canvas/device dimensions are large enough to
> cause this problem and forcefully disables anti-aliasing for all clips.
> This shouldn't really be a visual behavior change since the blitter
> already was downgrading from AA. The main advantage is that the clip
> stack will use SkRegion for BW clips exclusively instead of switching
> to use SkAAClip.
>
> It was decided to handle this at the clip stack level vs. a per-op
> decision since a non-AA large clip element used with SkAAClip (
> triggered by a smaller non-problematic op) would still show the bug.
>
> This is only a mitigation. The long-term solution is to use tiling for
> clipping as well as drawing (possibly by requiring the tiling to be
> handled by clients, with surface creation failing at sizes > 16k).
>
> Bug: chromium:1240718, skia:7998
> Change-Id: I1f4cae540bec4d44c6e1d8032ded9e95ff32b82f
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441456
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
TBR=reed@google.com,michaelludwig@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I6008cef5f7df48f27497e2ec75db14584c2acb68
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1240718, skia:7998
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441520
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This is a reland of 0f7c10ef56
Original change's description:
> Add sRGB 8888 colortype
>
> A color type that linearizes just after loading, and re-encodes to sRGB
> just before storing, mimicking the GPU formats that work the same way.
>
> Notes:
> - No mipmap support
> - No SkPngEncoder support (HashAndEncode's .pngs are ok, though?)
> - Needs better testing
>
> This is a re-creation of reviews.skia.org/392990
>
> Change-Id: I4739c2280211e7176aae98ba0a8476a7fe5efa72
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438219
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I5b6bb28c4c1faa6c97fcad7552d12c331535714d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441402
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Anti-aliased path rendering in the software backend has an internal
limit of +/-16384 per coordinate. Path rendering is triggered by draws
and clips. Draws are tiled at a high-level before entering the blitter,
so this limit will not be encountered. Coverage mask generation for
AA clips, however, is not tiled. Normally, it relies on the path being
clipped by the underlying device dimensions. When the device itself
is larger than 16384, then the clip ops can reach the blitter and
exceed the internal limit.
When this happens, SkScan::FillPath adds a hard rect clip, which is
what caused the mis-applied clip seen in the attached bug report.
This CL detects when the canvas/device dimensions are large enough to
cause this problem and forcefully disables anti-aliasing for all clips.
This shouldn't really be a visual behavior change since the blitter
already was downgrading from AA. The main advantage is that the clip
stack will use SkRegion for BW clips exclusively instead of switching
to use SkAAClip.
It was decided to handle this at the clip stack level vs. a per-op
decision since a non-AA large clip element used with SkAAClip (
triggered by a smaller non-problematic op) would still show the bug.
This is only a mitigation. The long-term solution is to use tiling for
clipping as well as drawing (possibly by requiring the tiling to be
handled by clients, with surface creation failing at sizes > 16k).
Bug: chromium:1240718, skia:7998
Change-Id: I1f4cae540bec4d44c6e1d8032ded9e95ff32b82f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441456
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This fixes an assertion failure uncovered by the fuzzer.
Bug: oss-fuzz:37469
Change-Id: I626c003cfa8a0bc65851899df3a7695dbe29200b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441311
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: Ie346a2dab7648e28e71ed0b6fd9331895644f1a1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441400
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
The last if check in this loop was unnecessary. It was an exact
duplicate of the first check at the top of the loop.
Change-Id: I08adc4f6df8577d168ae965220c0d9ddceb91121
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441240
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
During constant-folding, we baked in an assertion stating that any
const-typed variable reference ought to have an initial value, because
you can't declare a const variable without assigning a value. However,
function parameters are an exception to this rule! They are variable
references and are allowed to be const, but will not have an initial
value. (In this case, `const` just means you can't alter the value.)
In this case, all we needed to do was remove the assertion; we already
treated this case defensively and with the appropriate care.
Change-Id: I61242c6d08c59886c6992898f195771e6334f2b4
Bug: oss-fuzz:37465
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441239
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Originally, the cpu blur code could only deal with sigma <= 132. This
is due to limiting the gaussian to using a uint32_t for accumulation.
This change adds a tent filter for sigma > 132 but less < 2183. The
upper limit is not a problem because the GPU code limits sigma to 535
for both GPU and CPU. The output for GPU and CPU should be very
similar now.
Bug = skia:12338
Change-Id: I12299373911f42b914ee329a02ca81bdbd0763bd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440545
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Now that Context owns the errors pointer, there is no magic behind its
accessor and no reason not to just use a straight field access.
Change-Id: I3f771f458ffdaf95d6289ba5767535a78126cc0b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441312
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 0f7c10ef56.
Reason for revert: Unhappy rollers
Original change's description:
> Add sRGB 8888 colortype
>
> A color type that linearizes just after loading, and re-encodes to sRGB
> just before storing, mimicking the GPU formats that work the same way.
>
> Notes:
> - No mipmap support
> - No SkPngEncoder support (HashAndEncode's .pngs are ok, though?)
> - Needs better testing
>
> This is a re-creation of reviews.skia.org/392990
>
> Change-Id: I4739c2280211e7176aae98ba0a8476a7fe5efa72
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438219
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,brianosman@google.com,reed@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: Ie199535b9b65ec7c7fef3c773452ea06bdbd2d9c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441376
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This was another place where we needed to use
`getConstantSubexpression` to rebuild vectors/matrices; it is a more
robust approach than trying handle each ctor type individually. The
fuzzer found an edge case with double-casting matrices to vectors that
fell through the cracks with the original approach.
In adding additional tests, I also found a case that the constant-folder
seems to ignore, `bool4(x,x,x,x) == bool4(x)`. This does fold for ints
and floats, so this ought to be fixable in a followup, but it's not a
big deal either way; this is very unlikely to occer in real code.
Change-Id: I4d577c87ef7049306685ca95250ecdf93b1dbc06
Bug: oss-fuzz:37464
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441238
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
GCC 10.2.1 gives the following warning as error in a release build
../../src/core/SkString.cpp:227:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
227 | rec->data()[len] = 0;
which is detecting that fBeginningOfData is a char and that this code
cannot be reached with len == 0. Work around this by changing
fBeginningOfData to be an array of one char containing the empty string
by default.
While making this change, also make fBeginningOfData and fRefCnt
private.
Change-Id: Ic254bac465fcd02707a06010e0d7501520f7271d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441136
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
