This makes the blurcircles bench go from ~33us to ~8us on Windows desktop.
It will require layout test suppressions
Review URL: https://codereview.chromium.org/1311583005
- streamline how we define $here
- only make `cmake` when bootstrapping; it's a little less to build
BUG=skia:4269
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.9-Clang-x86_64-Release-CMake-Trybot,Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot
Review URL: https://codereview.chromium.org/1345663004
Displays each benchmark/skp with a graph showing a series of frame times.
Use the space bar to skip to the next benchmark.
Adds an option to hit ESC to quit VisualBench. Useful in fullscreen mode.
Review URL: https://codereview.chromium.org/1336043003
Blink is migrating away from SkBitmaps, so we need an SkImage-based
SkImageFilter source. This is pretty much a 1-1 equivalent of
SkBitmapSource.
To avoid duplication, relocate the SkImage deserialization logic
from SkPictureData to SkReadBuffer.
R=reed@google.com,robertphillips@google.com,senorblanco@chromium.org
Review URL: https://codereview.chromium.org/1343703005
Reason for revert:
http://build.chromium.org/p/client.skia.compile/builders/Build-Mac10.8-Clang-Arm7-Debug-Android/builds/4627
Original issue's description:
> SkPx: new approach to fixed-point SIMD
>
> SkPx is like Sk4px, except each platform implementation of SkPx can declare
> a different sweet spot of N pixels, with extra loads and stores to handle the
> ragged edge of 0<n<N pixels.
>
> In this case, _sse's sweet spot remains 4 pixels. _neon jumps up to 8 so
> we can now use NEON's transposing loads and stores, and _none is just 1.
> This makes operations involving alpha considerably more efficient on NEON,
> as alpha is its own distinct 8x8 bit plane that's easy to toss around.
>
> This incorporates a few other improvements I've been wanting:
> - no requirement that we're dealing with SkPMColor. SkColor works too.
> - no anonymous namespace hack to differentiate implementations.
>
> Codegen and perf look good on Clang/x86-64 and GCC/ARMv7.
> The NEON code looks very similar to the old NEON code, as intended.
> No .skp or GM diffs on my laptop. Don't expect any.
>
> I intend this to replace Sk4px. Plan after landing:
> - port SkXfermode_opts.h
> - port Color32 in SkBlitRow_D32.cpp (and move to SkBlitRow_opts.h like other
> SkOpts code)
> - delete all Sk4px-related code
> - clean up evolutionary dead ends in SkNx (Sk16b, Sk16h, Sk4i, Sk4d, etc.)
> leaving Sk2f, Sk4f (and Sk2s, Sk4s).
> - find a machine with AVX2 to work on, write SkPx_avx2.h handling 8 pixels
> at a time.
>
> In the end we'll have Sk4f for float pixels, SkPx for fixed-point pixels.
>
> BUG=skia:4117
>
> Committed: https://skia.googlesource.com/skia/+/82c93b45ed6ac0b628adb8375389c202d1f586f9TBR=mtklein@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4117
Review URL: https://codereview.chromium.org/1336423002
The new flow of calls for attaching a Stencil looks like:
Client
rt->attachStencilAttachment()
gpu->getStencilAttachment()
glgpu->createStencilAttachment()
glrt->completeStencilAttachment() //actually attaches
BUG=skia:
Review URL: https://codereview.chromium.org/1333383002
This file was generated using the whitelist_typefaces tool.
I tried out this file on 3 of the 100
CT slaves and './out/Debug/whitelist_typefaces --check' successfully returned 0.
BUG=skia:4336
Review URL: https://codereview.chromium.org/1344553004
SkPx is like Sk4px, except each platform implementation of SkPx can declare
a different sweet spot of N pixels, with extra loads and stores to handle the
ragged edge of 0<n<N pixels.
In this case, _sse's sweet spot remains 4 pixels. _neon jumps up to 8 so
we can now use NEON's transposing loads and stores, and _none is just 1.
This makes operations involving alpha considerably more efficient on NEON,
as alpha is its own distinct 8x8 bit plane that's easy to toss around.
This incorporates a few other improvements I've been wanting:
- no requirement that we're dealing with SkPMColor. SkColor works too.
- no anonymous namespace hack to differentiate implementations.
Codegen and perf look good on Clang/x86-64 and GCC/ARMv7.
The NEON code looks very similar to the old NEON code, as intended.
No .skp or GM diffs on my laptop. Don't expect any.
I intend this to replace Sk4px. Plan after landing:
- port SkXfermode_opts.h
- port Color32 in SkBlitRow_D32.cpp (and move to SkBlitRow_opts.h like other
SkOpts code)
- delete all Sk4px-related code
- clean up evolutionary dead ends in SkNx (Sk16b, Sk16h, Sk4i, Sk4d, etc.)
leaving Sk2f, Sk4f (and Sk2s, Sk4s).
- find a machine with AVX2 to work on, write SkPx_avx2.h handling 8 pixels
at a time.
In the end we'll have Sk4f for float pixels, SkPx for fixed-point pixels.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1317233005
The existing mask effect code in Ganesh is subject to snapping issues (when the created mask is redrawn). This artifact can be seen by rendering the original geometry (w/o blurs) and comparing that result to a rendering of the unblurred masks. W/o this patch the results do not match up (they are arbitrarily shifted by a pixel).
This patch will require rebaselining and suppressions.
Chromium layout tests suppressions are here:
https://codereview.chromium.org/1342683003/ (Add layout test suppressions for upcoming Skia roll)
Review URL: https://codereview.chromium.org/1338183002
- Add CMake v3.3.1 (latest) to DEPS.
- Add cmake/bot-cmake.sh to bootstrap CMake then build Skia using that.
Works on my Mac and Linux box, both with no system CMake installation.
CMake will be ~100M on disk. The first bootstrap takes a couple minutes,
and a no-op re-run of bot-cmake.sh takes 15-20 seconds. I thought about
having bot-cmake.sh fetch CMake instead of DEPS, but I'm not sure I can
handle updates, etc. as robustly as it can.
This will only work on Linux and Mac. CMake requires an older CMake on
Windows. It doesn't have an equivalent ./bootstrap there. Will have to
think about how Windows bots will work!
BUG=skia:4269
Review URL: https://codereview.chromium.org/1339603003
BitmapRegionSampler (uses SkImageDecoder) will often scale
to a power of 2 regardless of the sampleSize requested.
This is skbug.com/4319.
Consider a 60x60 image.
To decode a subset with sample size 3, we might ask for the
following.
[x, y, w, h] = [-15, -15, 30, 30]
sampleSize = 3
Since w = 30 and h = 30, this should give us a 10x10
result. Only the bottom right 5x5 quadrant of this 10x10
subset will actually be in the image. We should get a 5
pixel border on the top and left because we ask for 15
extra pixels on the top and left.
Unfortunately, SkImageDecoder will take our requested
sample size of 3, and then decide to use a sample size of
2. Not only will it scale the image by 2, but it will also
scale the border by 2. So while we are expecting pixel
data to begin at offset (5, 5) of the result bitmap, it
actually begins at offset (7, 7). Making things worse,
the pixels between (5, 5) and (7, 7) are uninitialized,
causing problems on Gold.
Options for fixing this include:
(1) Not testing decodes with a border.
(2) Changing the test to check the size of the output
bitmap.
(3) Disable the tests.
I think it's best to just disable these tests. We know
they don't work, so why do we need to see the results on
Gold?
BUG=skia:4319
Review URL: https://codereview.chromium.org/1313233007
