Change-Id: I2e69e62c49e153437b93e082419e6981f438dfc3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405262
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Also fixing a small problem with offsets that never appeared
because we never use this code path (but could)
Bug: skia:11947
Change-Id: I8c02c696797ea45d35fcab5746fbc079326e4539
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404897
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
Chromium has been updated to use makeAnalysisCanvas directly and there are
no more references to SkTextBlobDiffCanvas as a type in its code base.
Since the GlyphTrackingDevice extends SkNoPixelsDevice, any SkCanvas that
uses it is effectively a "no-draw" canvas. However, by returning a base
SkCanvas the text tracking now automatically happens in the context of
the base's AutoLayerForImageFilter handling it applies on every draw. This
means that drawing a text blob with an image filter that modifies the
transform state will now be analyzed in that context automatically
(simplifying code in chrome after this lands).
Another behavioral change is that all non-text draws will still go through
the base SkCanvas' virtuals and invoke the device function. Since it's an
SkNoPixelsDevice, it'll still be a no-op, it just happens a little later.
This won't really impact performance because oop-r already inspects their
operations and only plays back text and transform related ones to the
analysis canvas, so we shouldn't really see non-text draws being invoked
anyways.
Bug: chromium:1187246
Change-Id: I83f86571300751f385b3065dfe889f218fa1edc6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405196
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This includes several new array variants of existing APIs, DSLBlock now
supporting SymbolTables, and a couple of other minor changes needed by
the upcoming DSLParser.
Change-Id: I71feb268feb27cf7ff453cc59046091779bffe06
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404779
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
We no longer need to maintain a separate mapping table of intrinsic
function names in SkVM.
Change-Id: Ia3be89f9d2fc792adad2f06acc2373363497a6b7
Bug: skia:11961
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405277
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>
Introduce two new text properties to control the font size range when
auto-scaling text:
- plumb new json props ('mf' -- minimum font size, 'xf' -- maximum
font size)
- update the scale-to-fit binary search to use the specified extremes
Change-Id: I9e7e4915936a0be74bea473a520cf75acc05c84b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404781
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Change-Id: Ifd909e237bc3ed1ee9bcafccb5ddcc849ba106e4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405276
Auto-Submit: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
We no longer need to maintain a separate mapping table of intrinsic
function names in Metal.
Change-Id: Ib14b76d3a47a396c4a09adb11e0fd3c144501032
Bug: skia:11961
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405236
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is more efficient than looking up the intrinsic by name.
Change-Id: Iab8d3bc651a0574f783414ad6acae1772ab12668
Bug: skia:11961
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405116
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
If every argument passed to lessThan/greaterThan/lessThanEqual/
greaterThanEqual/equal/notEqual() is a compile-time constant, we now
detect this and optimize away the function call entirely.
Change-Id: I3415d21be6ef51b38b682a792bd118fad51957f5
Bug: skia:10835
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
If every argument passed to any() or all() is a compile-time constant,
we now detect this and optimize away the function call entirely.
Future CLs will perform a similar optimization on other intrinsic calls
which can be detected and eliminated at compile time, like lessThan().
Change-Id: Ie55aff538b1ccaf2b3bcf9a69573a85f081b7ade
Bug: skia:10835
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404417
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Based on the comments, the original motivations for not using AutoSource
in one spot were apparently that the source text was needed to display
error text after a failed compile. This doesn't seem to be the case
anymore; all tests still pass, generating the same error messages, and I
don't see a way for the source pointer to be used meaningfully after a
compile.
Change-Id: Iec45af6409e4f5ab7faa4bd79466c18a6242c2b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404337
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This simplifies intrinsic identification from our backends. Rather than
needing to manually track a list of strings in each backend, we can just
call `funcCall.function().intrinsicKind()` and use the shared enum.
In this CL, the GLSL backend has been converted to use the intrinsicKind
call. Other backends will be updated in followup CLs.
Change-Id: I47491655108a08b7414bfa293807d46ad948084a
Bug: skia:11961
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404898
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 is a reland of adadb95a9f
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 5e1f135376.
Reason for revert: breaking pixel test on chrome roll
Original change's description:
> Re-enable tessellation for cacheable strokes
>
> Now that the fixed count stroke tessellator has landed, these should
> hopefully not regress performance.
>
> Bug: skia:11138
> Bug: skia:11139
> Change-Id: I1a7d756e2a8a55f9ad4aaed716e4816b342b3b4f
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404398
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
TBR=egdaniel@google.com,csmartdalton@google.com
Change-Id: I723bbb3f6ee8f2cfbf80a1475b351a87f82e4d2b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:11138
Bug: skia:11139
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404919
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
The SkM44::RectToRect function matches the semantics of
SkMatrix::RectToRect(kFill_ScaleToFit). No other ScaleToFit variants are
ported over to SkM44.
skottie uses some instances of kCenter_ScaleToFit so that functionality
may need to be added in the future (in SkM44 or in skottie). There are
no current usages of the kStart and kEnd_ScaleToFit semantics.
The SkM44::mapRect() function is implemented to correspond to the
SkMatrix::mapRect() that returns the mapped rect (instead of modifying a
pointer) and always has ApplyPerspectiveClip::kYes. This was chosen to
keep its behavior simple and because perspective clipping is almost
always the right thing to do. In the new implementation there is no
longer a performance cliff to worry about (see below). For the timebeing
mapRect is hidden behind SkMatrixPriv::MapRect().
Performance:
I added benchmarks for mapRect() on SkM44 and SkMatrix that use the same
matrices to get a fair comparison on their different specializations.
SkMatrix has a very efficient mapRect when it's scale+translate or
simpler, then another impl. for affine matrices, and then falls back to
SkPath clipping when there's perspective. On the other hand, SkM44 only
has 2 modes: affine and perspective.
On my desktop, with a Ryzen 9 3900X, here are the times for 100,000 calls
to mapRect for different types of matrices:
SkMatrix SkM44
scale+translate 0.35 ms 0.42 ms
rotate 1.70 ms 0.42 ms
perspective 63.90 ms 0.66 ms
clipped-perspective 138.0 ms 0.96 ms
To summarize, the SkM44::mapRect is almost as fast as the s+t specialization
in SkMatrix, but for all non-perspective matrices. For perspective matrices
it's only 2x slower than that specialization when no vertices are clipped,
and still almost 2x faster than the affine specialization when vertices are
clipped (and 100x faster than falling back to SkPath).
Given that, there's the open question of whether or not keeping an affine
specialization is worth it for SkM44's code size.
Bug: skia:11720
Change-Id: I6771956729ed64f3b287a9de503513375c9f42a0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402957
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
We were relying on a compile thing for this check which isn't really
right. We probably got away with it since the only bad gpu was Mali
400 and that probably never compiled with vulkan enabled. But still we'd
end up in weird cases were a different backend would change how it
worked here depending on if vulkan happen to also be compiled or not.
Change-Id: Ie06519e110cd7eb92384bce4ec3d8211cfc92488
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404917
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Change-Id: Ibb1c563fccae980ad23fac7c41bc5dc91a9925c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404876
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
This adds support for mipmap generation in the simplest case:
* power-of-two
* non-sRGB
* not BGR
The mipmaps are generated with a compute shader that reads from a SRV
of one miplevel and then writes to a UAV at miplevel+1. Miplevel+1 is
then transitioned to a resource state that can be read from, and the
process continues for miplevel+1 and miplevel+2, etc.
Change-Id: Id467d0e56d5408559d3cacec1514f1b43d76d640
Bug: skia:10446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/392917
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
A constructor like `float3(five)` is not a compile-time constant, so we
miss optimization opportunities like folding. Constant variables inside
splat constructors are now replaced when optimization is on, so this
would optimize down to `float3(5.0)` and be eligible for folding.
Change-Id: I4bf6f52a48ef733e6b24791d02687081194ef488
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404676
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Previously, a failure in converting a parameter while creating a
function would result in an assertion failure. This fixes it to be a
non-fatal error.
Change-Id: I7a526eff9696847f70f0de78e71e7c23488c1254
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404339
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Change-Id: I5309005146b8121528ad23589fa64cc6bf286aee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402578
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Now that the fixed count stroke tessellator has landed, these should
hopefully not regress performance.
Bug: skia:11138
Bug: skia:11139
Change-Id: I1a7d756e2a8a55f9ad4aaed716e4816b342b3b4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404398
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
A constructor like `float2(one, two)` is not a compile-time constant, so
we miss optimization opportunities like folding. Constant variables
inside compound constructors are now replaced when optimization is on,
so this would optimize down to `float2(1.0, 2.0)` and be eligible for
folding.
Change-Id: I80dd421f61d4eed21278805e2dc26d198a678e52
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404657
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This handles the case where a filter effect input is StrokePaint or
FillPaint, but the referencing element has a 'none' paint specified
(explicitly or via parsing error, as in the original bug report).
Bug: skia:11213
Change-Id: Ie710a9fc5ccb3c24014735e01c70a0ba42c7a99d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404696
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
This reverts commit a2335098a6.
Reason for revert: it was not breaking chrome roll
Original change's description:
> Revert "Do reordering & memory budgeting after onFlushCB"
>
> This reverts commit 566cf465fc.
>
> Reason for revert: I think this one is the cause
>
> Original change's description:
> > Do reordering & memory budgeting after onFlushCB
> >
> > This allows the CCPR atlas manager to setup its atlas before
> > we do any memory budgeting. That way the atlas size is known.
> >
> > Bug: skia:10877
> > Change-Id: I9d73df29d1e8412b714b00dbf2ebff47025d3e3e
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403857
> > Commit-Queue: Robert Phillips <robertphillips@google.com>
> > Auto-Submit: Adlai Holler <adlai@google.com>
> > Reviewed-by: Robert Phillips <robertphillips@google.com>
>
> TBR=robertphillips@google.com,adlai@google.com
>
> Change-Id: Iaf13f8abb060c52df4a6a10ba45896a0a26bc662
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:10877
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404476
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Greg Daniel <egdaniel@google.com>
# Not skipping CQ checks because this is a reland.
Bug: skia:10877
Change-Id: Iec2956bfcd828ad2e329f6d5c6a0732e55341919
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404777
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
The modifier pool is in the Context now and doesn't need to be passed
separately.
Change-Id: I92388ebfd4dfd69360455efa1b1e2558c512a950
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404341
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 048b5a2967.
Reason for revert: Okay feeling confident this guess is right about who is breaking chrome roll.
Original change's description:
> Transform verts using nonsquare matrices when available.
>
> We were previously doing a square-matrix multiply then discarding one
> third of the result; now, when available, we just get the result we need
> via a non-square multiply.
>
> Change-Id: Ie13ae6f2c7f23e3a4c1f2c4eeb6361a97cdccf67
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403079
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,brianosman@google.com,johnstiles@google.com
Change-Id: I5e1026def7e7ade019c2543b6f30387bec1bc004
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404596
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This reverts commit 566cf465fc.
Reason for revert: I think this one is the cause
Original change's description:
> Do reordering & memory budgeting after onFlushCB
>
> This allows the CCPR atlas manager to setup its atlas before
> we do any memory budgeting. That way the atlas size is known.
>
> Bug: skia:10877
> Change-Id: I9d73df29d1e8412b714b00dbf2ebff47025d3e3e
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403857
> Commit-Queue: Robert Phillips <robertphillips@google.com>
> Auto-Submit: Adlai Holler <adlai@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=robertphillips@google.com,adlai@google.com
Change-Id: Iaf13f8abb060c52df4a6a10ba45896a0a26bc662
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10877
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404476
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
