Mechanical.
Bug: skia:11837
Change-Id: Ic302ee314ad73ce034c8daac38416a8249a125a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442276
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Very originally, skif::Mapping::DecomposeCTM() and
SkBaseDevice::setDeviceCoordinateSystem assumed that if the canvas
matrix was invertible, then any scale decomposition would produce a
valid device coordinate system. This proved not to be true and fuzzers
quickly caught it, but I had attempted to address it by forcing
SkCanvas to do extra work so that the above two functions remained
unchanged.
However, it's become apparent that even making the assumption that the
product of two invertible matrices remains invertible does not always
hold true in the wonderful world of floating point math.
Instead, this rewrites DecomposeCTM and setDeviceCoordinateSystem to
return bools, allowing them to fail. This cleans up some of the earlier
checks that SkCanvas makes while computing the skif::Mapping, and it
also ensures that once we fold in the prior device's transform, the
net layer->global transform remains valid. If any of this fails, it
just gets rid of the new device and sets the clip to empty, basically
preventing drawing until the invalid layer has been restored.
Bug: chromium:1239968, chromium:1240685
Change-Id: Ib9ce8f95859e726a9eacf1154f6eef8dd3995500
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442017
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Before running this script, you'll need someone from infra team to give
your @google.com account access to the Google Cloud fuzzer repo. Once
that's been done, run this Python script and it will automatically
recreate the fuzzer corpus from our SkSL test inputs and upload it to
the cloud.
Change-Id: I804fdf7933a99b92dd1640d9af17530d4db97a4e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442001
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The entire ASTNode is probably going away soon, but this is a decent
place to start. Checking the fuzzer logs, we had 0% coverage in here,
which makes sense because it's unreachable by any normal means.
Change-Id: I396464e3e613d46e990b629c4fc991c11f6110fa
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442000
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>
+small fix for placeholder in getGlyphPositionAtCoordinate
Bug: skia:12322
Change-Id: I8f03c5c808db54fc9742e5817768db4a088bc5b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440458
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
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>
