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>
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>
NaNs can't be correctly sorted.
Bug: 757650
Change-Id: Id1ca2fe1d1de7884da2a64ceef9491b1da7e8e77
Reviewed-on: https://skia-review.googlesource.com/37220
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
There was no way to get this behavior without triggering an error before.
Bug: skia:
Change-Id: Id9cb9090e47226dadad0032f06ec205dd2538dcc
Reviewed-on: https://skia-review.googlesource.com/37001
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Things ran slower when we attempted to turn it on,
and we've already removed the analog in SkJumper_stages.cpp.
Change-Id: I61afa38990bf54d1bff2b1902f09a14df4e17da9
Reviewed-on: https://skia-review.googlesource.com/37080
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Flag no longer defined.
Change-Id: I4b4aa33ecd23b485cf80d79882f52da96c82a567
Reviewed-on: https://skia-review.googlesource.com/36822
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
We were ignoring the path renderer flag when drawing GMs or SKPs.
Bug: skia:
Change-Id: Iee443fb70f1faec65e46925fa0e3cea3716d448d
Reviewed-on: https://skia-review.googlesource.com/36861
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
