generate method links from
fiddle names to keep them
consistent and unique.
Docs-Preview: https://skia.org/?cl=38727
Bug: skia:6898
Change-Id: I3434801b46002a3a9095e007d456e9e871307304
Reviewed-on: https://skia-review.googlesource.com/38727
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
This is then used when need to update GPU only buffers with data of size
greater than 65536. We create a temporary transfer buffer and then copy
that buffer into our GPU buffer.
Bug: skia:
Change-Id: I4bb9cb660f2ac1ccbbd1b508bb4ca6876342136f
Reviewed-on: https://skia-review.googlesource.com/38725
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
qualify bookmaker links to remove
file reference if intra-file and
add class reference if part of
a class
TBR=caryclark@google.com
Docs-Preview: https://skia.org/?cl=38722
Bug: skia: 6898
Change-Id: Ie0548485a6e3f596efc0f15b819bd5060e983a5b
Reviewed-on: https://skia-review.googlesource.com/38722
Reviewed-by: Cary Clark <caryclark@skia.org>
Commit-Queue: Cary Clark <caryclark@skia.org>
This is a prerequisite for being able to resize the atlas with impunity.
Change-Id: Iccc9c7ced43f38a7d8483a7bd12a458d59a3453a
Reviewed-on: https://skia-review.googlesource.com/38362
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
The tiny path added to PathTest.cpp has
tinier cross products (e.g. 1e-12)
so appears to be a series of unbending
lines as far as getConvexity is concerned.
This point fix looks for paths that
do not bend left or right or go backwards,
but do have a bounds, and calls them
concave.
A better fix may be to consider empty
and degenerate paths to be concave
instead of convex; I don't know if
anyone relies on the existing behavior.
Another better fix may be to change
the math to compute the path turns
even though the numbers are very small;
on the surface, very difficult.
R=bsalomon@google.com,reed@google.com
Bug:755839
Change-Id: Ie2280f3f0b95fecab2899f5fc579fd39258e0647
Reviewed-on: https://skia-review.googlesource.com/38720
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
SkIsS16 can be replaced with SkTFitsIn<int16_t> and SkIsU16 is never
used.
Change-Id: I734f677149fab102cdb295a7b34faa3e3089134a
Reviewed-on: https://skia-review.googlesource.com/38600
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This reverts commit 76323bc061.
Reason for revert: Breaking NUC bots in threaded gm comparison:
https://chromium-swarm.appspot.com/task?id=382e589753187f10&refresh=10
Original change's description:
> Threaded generation of software paths
>
> All information needed by the thread is captured by the prepare
> callback object, the lambda captures a pointer to that, and does the
> mask render. Once it's done, it signals the semaphore (also owned by the
> callback). The callback defers the semaphore wait even longer (into the
> ASAP upload), so the odds of waiting for the thread are REALLY low.
>
> Also did a bunch of cleanup along the way, and put in some trace markers
> so we can monitor how well this is working.
>
> Traces of a GM that includes GPU and SW path rendering (path-reverse):
>
> Original:
> https://screenshot.googleplex.com/f5BG3901tQg.png
> Threaded, with wait in the callback (notice pre flush callback blocking):
> https://screenshot.googleplex.com/htOSZFE2s04.png
> Current version, with wait deferred to ASAP upload function:
> https://screenshot.googleplex.com/GHjD0U3C34q.png
>
> Bug: skia:
> Change-Id: I3d5a230bbd68eb35e1f0574b308485c691435790
> Reviewed-on: https://skia-review.googlesource.com/36560
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=egdaniel@google.com,mtklein@google.com,bsalomon@google.com,robertphillips@google.com,brianosman@google.com
Change-Id: Icac0918a3771859f671b69ae07ae0fedd3ebb3db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/38560
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This changes the cases which require two compares into single compares
by relying on squirrely bits of the C++ specification.
Change-Id: I2c14e461b571bb94f586c14db4eaeadfd06b628b
Reviewed-on: https://skia-review.googlesource.com/38220
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The most interesting parts of this are how plus interacts with partial
coverage. Plus needs its clamp to happen after the lerp.
Luckily, some of its math folds away:
d' = clamp[ d*(1-c) + (s+d)*c ] ==
clamp[ d - dc + sc + dc ] ==
clamp[ d + sc ]
What's nice there is that coverage can be folded into the src term.
This suggests that we can re-write the plus stage to clamp internally
(and thus, be viable for 8-bit) if we always pre-scale with coverage.
We don't have a way to pre-scale with 565 coverage until now, but
it's only a step or two away from there. We can use the alternate
formulation we derived for alpha for lerp_565, calculating the alpha
coverage from red, green, and blue coverages _and_ the values of src
and dst alpha.
While we already pre-scale srcover today for 8-bit or constant coverage,
we cannot do the same for 565. When evaluating the expression
d' = s + (1-a)d
we need the a term to be pre-scaled with red's coverage when calculating
dr', with blue's when calculating db', etc. Essentially we need to
carry around a bunch of extra values, and we've got no way to do that.
So instead, we'll just carefully pre-scale plus with any coverage, and
keep post-lerping srcover when we have 565 coverage.
Change-Id: I7a7a52eec7d482e1b98bb8a01ea0a3d5e67bef65
Reviewed-on: https://skia-review.googlesource.com/38300
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
also fixed minor bookmaker bugs so canvas
include and online docs are (bookmaker detected)
error-free
TBR=reed@google.com
Docs-Preview: https://skia.org/?cl=37840
Bug: skia:
Change-Id: Ifcec9c751105444047c37d89fd984dbd4dfd1913
Reviewed-on: https://skia-review.googlesource.com/37840
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Cary Clark <caryclark@skia.org>
This reverts commit e84c087e62.
Reason for revert: ANGLE is unhappy
Original change's description:
> Switch atlas clients over to using absolute texture coordinates
>
> This is a prerequisite for being able to resize the atlas with impunity.
>
> Change-Id: I509816c8d6f38fbc92fa39aeab303b42ab09f58b
> Reviewed-on: https://skia-review.googlesource.com/37560
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=egdaniel@google.com,jvanverth@google.com,robertphillips@google.com,brianosman@google.com
Change-Id: I329efd642c22e11a5c576a4632fc557759b200d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/38400
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
The flag is no longer used.
Change-Id: I39156ef5683538263c2302f2fe3ba779e55dbc47
Reviewed-on: https://skia-review.googlesource.com/38360
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This is a prerequisite for being able to resize the atlas with impunity.
Change-Id: I509816c8d6f38fbc92fa39aeab303b42ab09f58b
Reviewed-on: https://skia-review.googlesource.com/37560
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This lets you check if the work's done without blocking.
Seems handy.
Change-Id: Ie27c7b6fe0d01262b6a777abbc18b0de108641c0
Reviewed-on: https://skia-review.googlesource.com/38120
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
All information needed by the thread is captured by the prepare
callback object, the lambda captures a pointer to that, and does the
mask render. Once it's done, it signals the semaphore (also owned by the
callback). The callback defers the semaphore wait even longer (into the
ASAP upload), so the odds of waiting for the thread are REALLY low.
Also did a bunch of cleanup along the way, and put in some trace markers
so we can monitor how well this is working.
Traces of a GM that includes GPU and SW path rendering (path-reverse):
Original:
https://screenshot.googleplex.com/f5BG3901tQg.png
Threaded, with wait in the callback (notice pre flush callback blocking):
https://screenshot.googleplex.com/htOSZFE2s04.png
Current version, with wait deferred to ASAP upload function:
https://screenshot.googleplex.com/GHjD0U3C34q.png
Bug: skia:
Change-Id: I3d5a230bbd68eb35e1f0574b308485c691435790
Reviewed-on: https://skia-review.googlesource.com/36560
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This extra ld pass can merge all our many redundant constants,
both within an instruction set and across them.
This should save a bunch of code size on x86-64, with no other impact.
It cuts 12K off my local build of ok.
Change-Id: Ib2bb4adf88564aca45e55ee53dcf6584265c7dbe
Reviewed-on: https://skia-review.googlesource.com/37940
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Bug: chromium: 758161
Change-Id: I2472ff59af2fab05d94d88d5effb44828e8a5132
Reviewed-on: https://skia-review.googlesource.com/37800
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: Id626f954fe45546a015a1bd423f19cca5f8967a9
Reviewed-on: https://skia-review.googlesource.com/37861
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
From local testing, TSAN causes this to happen for 40-50 GMs in the
middle of a DM run. Having this message would have saved me a couple
hours of head-scratching and debugging.
Best theory about the TSAN thing is that it interferes with a driver
thread that's reclaiming freed resources, but that's just a guess.
Bug: skia:
Change-Id: Ie6759fd2f22953595920cb271e2317c5ed1a0941
Reviewed-on: https://skia-review.googlesource.com/37441
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Only blitAntiH & blitMask/kA8 for now, but hopefully we can extend for
blitRect & blitMask/kLCD16 also.
Change-Id: I5e888d49c0c11f2f1fc595dbfb382044fc224edc
Reviewed-on: https://skia-review.googlesource.com/37542
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
NaNs can't be correctly sorted.
Don't run the unit test on VK backend, since it requires large (>64K bytes) vertex buffer uploads.
Bug: 757650
Change-Id: I667693f135a090a5d9076bb7a2ec6879fc06d645
Reviewed-on: https://skia-review.googlesource.com/37484
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Greg Daniel <egdaniel@google.com>
When Skia's built with an interestingly advanced instruction set
baseline like SSSE3 or SSE4.1, we end up with two distinct copies of
some SkOpts functions, one default in SkOpts.o and one specialization
from SkOpts_{ssse3,sse41}.o. These functions are static, and so are
technically unrelated, even though they're the same code compiled with
the same instructions available. They're going to be identical.
What we want here is to remove static but mark them as inline instead.
In this case inline means "if the linker sees multiple copies of this,
that's cool, just pick any one arbitrarily". That's just what we want.
Now, when I disassemble a binary before and after this change, I do see
the redundant routines removed. However, the file size change is
minimal... I suspect that this must mean the linker has noticed that we
had identical code and physically folded the two logically independent
routines. I don't know how prevalent this optimization is, though, so
it doesn't hurt to give it more of a "one copy please" hint with inline.
There may also be a difference here between the binary size (~unchanged)
and the in-memory layout of that binary?
Change-Id: Id9c8f0ffc84aa1c9a066c22b623d34adab281857
Reviewed-on: https://skia-review.googlesource.com/37501
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
As a preface to having all the atlas texture coordinates be absolute they must all first be integers. In the case of the small path renderer that means that the rect for the DF case must be bloated out a bit.
Change-Id: I9969fcfe9d3ae3247a2964e2ca79cad522ccad9e
Reviewed-on: https://skia-review.googlesource.com/37360
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
There's no reason to call Init_ssse3() if we know Skia's built globally
with SSSE3. And there's definitely no reason to call Init_ssse3() if
Skia's build globally with SSE4.1+.
These are the only places the Init_foo() methods are called, and those
in turn are the only places that refer to their optimized routines, so
guarding like this allows redundant routines to be dead-code stripped by
the linker.
There are still situations where we end up with two copies of the same
routine, compiled at _the same_ optimization level. If you're on a Mac
and have SSSE3 or SSE4.1 as your global baseline instruction set, you'll
get two copies, one from SkOpts.o's defaults, and one from
SkOpts_{ssse3,sse41}.o's "better" routines. I'm still thinking about
how to best fix this. Might just be as simple as removing "static" and
letting the linker dedup.
This cuts off about 70K of code on a build of ok.
Change-Id: Ia349d2c5299072bbd43966132798500de059b9ca
Reviewed-on: https://skia-review.googlesource.com/37600
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
GrContextOptions has an SkExecutor field, allowing clients to supply a
thread pool. If present, the GrContext will create an SkTaskGroup that
can be used for internal threading work.
Bug: skia:
Change-Id: I8b01245515a21a83f9fe838caf0a01c9a26c0003
Reviewed-on: https://skia-review.googlesource.com/37580
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Set doConsumeDegenerates to false when calling SkPath::Iter::next() for
all paths which are not in screen space. These lines are not degenerate
for world space paths.
Note: this change fixes only GrTessellatingPathRenderer and
GrDefaultPathRenderer. GrMSAAPathRenderer still exhibits the bug.
Bug: skia:6987
Change-Id: Ie3d494703211925c77052c68513948484e341486
Reviewed-on: https://skia-review.googlesource.com/37522
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This reverts commit 267641a90c.
Reason for revert: Seems to be turning the bots red
Original change's description:
> Fix artifacts on tiny stroked paths scaled up a lot.
>
> Set doConsumeDegenerates to false when calling SkPath::Iter::next() for
> all paths which are not in screen space. These lines are not degenerate
> for world space paths.
>
> Bug: skia:6987
> Change-Id: I411faf594bf8a15891bfff08691e86679b7741ac
> Reviewed-on: https://skia-review.googlesource.com/36881
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
TBR=bsalomon@google.com,senorblanco@chromium.org
Change-Id: I0d5a14670126ab3e0d99083a500ec8d3d0ef9961
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:6987
Reviewed-on: https://skia-review.googlesource.com/37440
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 20af6d12ee.
Performance regressions on Android and Flutter
Change-Id: If70edbe85aa251f298eddf18a89ba2cf56ed94fb
Reviewed-on: https://skia-review.googlesource.com/37340
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
BUG=chromium:749147
Change-Id: I2d4259805300c3f5ed9d25e142e9f12570c59781
Reviewed-on: https://skia-review.googlesource.com/37121
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
If an SkPathRef is constructed from arbitrary memory, it might not be
valid. However, any SkPathRef should be able to be destroyed cleanly.
An alternative to this would be to have CreateFromBuffer always do
the validation (even in release builds), return null for invalid ones,
and do the cleanup itself, but this seems like extra complication and
maybe not something general release builds want.
Bug: chromium: 752755
Change-Id: I1d509a5d5d0b173c20162ff79d731d6c8b4b6fb4
Reviewed-on: https://skia-review.googlesource.com/37321
Commit-Queue: Adrienne Walker <enne@chromium.org>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This is like an op, but only has one virtual, and always runs before
any ops prepare. To be used in threaded software mask rendering
(to schedule ASAP uploads).
Bug: skia:
Change-Id: I647482e2472d7321f3685e5bdbe49e10ac59c0b1
Reviewed-on: https://skia-review.googlesource.com/37160
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The method already always returns true, except in a single case after
asserting.
Change-Id: Icf241a8af04220d459c0782ffd9b74c34c753236
Reviewed-on: https://skia-review.googlesource.com/37161
Reviewed-by: Chris Blume <cblume@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
