Known hacks for now:
- only default typeface
- only ascii support
Fonts have several limitations for now.
SkParagraph (our temporary backend) wants a fontmgr up front,
rather than just relying on the typefaces in its styles. This makes it
hard to inter-op with our JS api. Not a long-term problem, as this
backend is short-term. The hacky work-around is just to pass NULL for
the typeface for now.
Related but different, I haven't yet figured out how to "return" a
JS Typeface object. Something about bare-pointers and sk_sp. I'll figure
it out eventually, but for now I just set the output slot to null
as well. (there's a TODO in the .cpp)
Ascii support
JS strings are UTF16 (afaik). However, our current backend thinks in
terms of UTF8 offsets. Plus, (at the moment) when I try to access the
JS string for C++, it coerces to utf8 (std::string).
We can fix both of these eventually, but for now I'll just test with
ascii input characters, and the API can still work.
Change-Id: I62ca71b0b45d017ac8e3881c06720776dc2d75a1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405400
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Julia Lavrova <jlavrova@google.com>
This makes the class name conform to the same pattern as the other
tessellation ops: stroke tessellation ops begin with GrStroke* and
fill tessellation ops now begin with GrPath*.
Change-Id: I454341ec95438637ee2a4e501a374f8f59622550
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405018
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
It was possible that multiple threads could detect that an entry did not
exist in the cache, both create a new entry, and both add to the cache.
The first to put an entry into the cache would be what subsequent
threads would retrieve from the cache.
Re-organize the code to avoid this race, make it easier to see that
typefaces created from data are not cached, and only take the mutex
once when using the cache.
Change-Id: I9a45a85ecc142d03d901037519eea0e56d30e877
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405436
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Copying textures has been implemented but the caps flag wasn't set. Also
adds some comments about format requirements.
Change-Id: I8b9b3b9c88c72fad44a3a7191fc17054d5def938
Bug: skia:10446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403599
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Uses an approximate triangle filter to replace the simple bilerp
in these cases.
Change-Id: I7cd32a5bce168a99563d0e834413a58c486cb6f9
Bug: skia:10446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404976
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
- SkCanvas no longer keeps fIsScaleTranslate bool that has to stay in
sync with the type of the matrix.
- No more fast or slow path for quickReject, the Sk4f code has been
completely removed.
- Uses SkM44::mapRect instead of SkMatrix::mapRect. This is slightly
slower for S+T, but much faster for other transforms. I'm hopeful we
won't notice the regression in the grand scheme for S+T, since the
code is a lot simpler now.
- The final isFinite() and intersects() check for quickReject uses
SkRect's functions instead of hand-written SSE/NEON. If we think this
is optimization is necessary, I'm hoping we can rewrite it in terms
of skvx instead of specific instructions.
- Consolidated how the quick-reject bounds outsetting into
computeDeviceClipBounds, and added an option to skip outsetting for
the one call site that doesn't want it.
Bug: skia:10987
Change-Id: I3cf2a73636cdeed06d12cab4548cfb94d1eb074a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405198
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Mike Reed <reed@google.com>
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>
