For the simplicity of this CL, I haven't enabled DAA for init-once yet.
The current init-once is only enabled for draw path, and it simply
generates the dev path in the init-once phase.
Bug: skia:
Change-Id: Ie9a9ef9fc453acbdeb48b06b93d578c626961e3f
Reviewed-on: https://skia-review.googlesource.com/87784
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Herb Derby <herb@google.com>
BUG=skia:7515
Change-Id: Iab31e8cadfaa1ce09d85aab9cc84a3e614ea5e45
Reviewed-on: https://skia-review.googlesource.com/100420
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I16d9293cbc0bef1bdce1260d1bd9b43d8853d070
Reviewed-on: https://skia-review.googlesource.com/93641
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Herb Derby <herb@google.com>
These don't seem to be used by anyone anymore so lets kill them.
Bug: skia:
Change-Id: I7908a9c9357e9e3b3166af9a14899dab522c3f11
Reviewed-on: https://skia-review.googlesource.com/97144
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Bug: skia:
Change-Id: If110f1716d2ad3b967aadca1c61d3e22386e17b1
Reviewed-on: https://skia-review.googlesource.com/94862
Commit-Queue: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
and SkPictureAnalyzer
Bug: skia:
Change-Id: I394eca648234b1a69e6f9a0a88c407366a33d079
Reviewed-on: https://skia-review.googlesource.com/87791
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Some interesting things are starting to fall out already,
like the fact that I needed to add a gamma_dst stage to
be able to draw into gamma-transfer-fn destinations.
I've also had to pass an SkAlphaType through to the linearize
functions so that they can maintain premul invariants. I'm not
sure this is actually a good idea... if you can, please double-
check my logic at SkRasterPipeline.cpp:128?
If it's correct logic, I'm going to need to do it all over the place.
But I imagine you don't do this and somehow get away with it.
Change-Id: I42cd9b161b54287d674225103ad9e19f8b388959
Reviewed-on: https://skia-review.googlesource.com/84680
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I054560b66c6cde346d939015326d8547879d2c4b
Reviewed-on: https://skia-review.googlesource.com/81160
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
This is identical to 70221 except for 3 lines inside SkFlexibleTaskGroup2D::work
to bypass the false-positive warning. We cannot reproduce the error the android
roller generated so we'll have to try and see.
The detailed warning can be found in:
https://skia-review.googlesource.com/c/skia/+/78720
TBR: mtklein@google.com
Bug: skia:
Change-Id: I3e2f414581dbd1398482cf45cf4f43eaf0535651
Reviewed-on: https://skia-review.googlesource.com/79321
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
This reverts commit 07a42411f8.
Reason for revert: This looks to be breaking the Android roll. See https://googleplex-android-review.googlesource.com/c/platform/external/skia/+/3295488
external/skia/src/core/SkTaskGroup2D.cpp:73:28: error: releasing mutex 'rowData.fMutex' that was not held [-Werror,-Wthread-safety-analysis]
rowData.fMutex.unlock();
Original change's description:
> Renaming and refactoring to prepare for init-once threaded backend
>
> Bug: skia:
> Change-Id: I39b1d73b612a9c133847dd7361d634a0351659f1
> Reviewed-on: https://skia-review.googlesource.com/70221
> Reviewed-by: Herb Derby <herb@google.com>
> Commit-Queue: Yuqian Li <liyuqian@google.com>
TBR=mtklein@google.com,herb@google.com,liyuqian@google.com
Change-Id: I701e6c62f6f437a6a285953b45b2e58cf7f0b6e5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/78720
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit 39631f3df1.
Reason for revert: break google3 rool
Original change's description:
> Add Atlas Text interface for rendering SDF glyphs.
>
> This new API is built upon SDF text atlas code from the GPU backend. Unlike using the GPU
> backend to draw text, this set of interfaces allows the client to render the SDF glyphs. The
> client issues text draws to potentially multiple targets and then the client flushes. The
> client then gets commands from Skia with data to put into a texture atlas and vertices to
> draw that reference the texture. The client is responsible for creating the texture, uploading
> the SDF data to the texture, and drawing the vertices provided by Skia.
>
> Change-Id: Ie9447e19b85f0ce1c2b942e5216c787a74f335d3
> Reviewed-on: https://skia-review.googlesource.com/59360
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,bsalomon@google.com,robertphillips@google.com
Change-Id: I4aad0c99e645b476fd8ba25731f2a10e8802bb25
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/73420
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This new API is built upon SDF text atlas code from the GPU backend. Unlike using the GPU
backend to draw text, this set of interfaces allows the client to render the SDF glyphs. The
client issues text draws to potentially multiple targets and then the client flushes. The
client then gets commands from Skia with data to put into a texture atlas and vertices to
draw that reference the texture. The client is responsible for creating the texture, uploading
the SDF data to the texture, and drawing the vertices provided by Skia.
Change-Id: Ie9447e19b85f0ce1c2b942e5216c787a74f335d3
Reviewed-on: https://skia-review.googlesource.com/59360
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 1e09e461d2.
Change-Id: I95d5544a7baaa078536790493ce4119816a77e94
Reviewed-on: https://skia-review.googlesource.com/72903
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 5627d65146.
Reason for revert: Google3
Original change's description:
> Add method to sk_gpu_test::TestContext to automatically restore the previous context.
>
> The motivation for this is to allow a GM to create a GL context, do some some work in it, and then return to the context that was set when it was invoked.
>
> Change-Id: Ie8496072a10f8f3ff36a08889e593a6ca961b61a
> Reviewed-on: https://skia-review.googlesource.com/70720
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=bsalomon@google.com,brianosman@google.com
Change-Id: Ifb79638c9d4500ca3be9a5be39a5ad78b20247c1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/72981
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The motivation for this is to allow a GM to create a GL context, do some some work in it, and then return to the context that was set when it was invoked.
Change-Id: Ie8496072a10f8f3ff36a08889e593a6ca961b61a
Reviewed-on: https://skia-review.googlesource.com/70720
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These are no longer used outside of Skia, so make them private.
Change-Id: I735bb39c10553885cc6051aebddeff150ba4caa9
Reviewed-on: https://skia-review.googlesource.com/59180
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
The GN->Android.bp script runs with target_cpu="none",
but Android needs SkJumper_generated.S. Just skip it
explicitly for WASM.
Change-Id: I07b9761c591d48198460ce6300ed3bc9fd02a487
Reviewed-on: https://skia-review.googlesource.com/49903
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Fix core.gni to use not use Assembler for none cpu.
Right now, there are no outputs because we aren't compiling
dm or nanobench. However, this still compiles the skia
library and creates two executables, so it's a good canary
for a real WASM build.
Additional note: the two executables in question don't draw
anything to the screen via GL, which is still not possible with
Skia+WASM.
Bug: skia:
Change-Id: I0d767467e94e40d01070e34223dd90e96f1c96f2
Reviewed-on: https://skia-review.googlesource.com/49540
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: chromium:762167
Change-Id: Ia23f6dbfc0466aef4ca9d1a5b9ff343d79dc83bb
Reviewed-on: https://skia-review.googlesource.com/47460
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I have text_16_AA_FF -> 8888 (forcing RP) faster than head now on my
laptop. I'm feeling confident that we can make this perform well.
After looking at performance a bit more today, it looks like everything
is within what I'd consider comparable in performance, especially on
ARM. On x86-64 it looks like big bulk blits get a little slower and
small mask blits get a little faster.
Quality looks good, and maybe improved for 565.
There are fewer platform-specific differences now in _lowp, and I think
they're few enough now that we could even consider completing the
unification by folding the 8-bit and float code together. Rename
"div255()" to "rebias()", slap on a few coats of paint...
Guarded for Chrome with SK_JUMPER_LEGACY_LOWP.
Change-Id: I36309c07cf736f3cb31952cca66030ad56026318
Reviewed-on: https://skia-review.googlesource.com/45982
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Chrome would like to perform cpu-side preprocessing for gpu draws in parallel.
They do not want to go through a picture (since they have their own display list format).
The general idea is that we add a new SkDeferredDisplayListRecorder class to
perform all of Ganesh's cpu-side preprocessing ahead of time and in parallel.
The SkDDLRecorder operates like SkPictureRecorder. The user can get an SkCanvas
from the SkDDLRecorder and feed it draw operations. Once finished, the user
calls 'detach' to get an SkDeferredDisplayList. All the work up to and
including the 'detach' call can be done in parallel and will not touch
the GPU. To actually get pixels the client must call SkSurface::draw(SkDDL)
on an SkSurface that is "compatible" with the surface characterization
initially given to the SkDDLMaker.
The surface characterization contains the minimum amount of information Ganesh needs
to know about the ultimate destination in order to perform its cpu-side work
(i.e., caps, width, height, config).
Change-Id: I75faa483ab5a6b779c8de56ea56b9d90b990f43a
Reviewed-on: https://skia-review.googlesource.com/30140
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 6d13575108.
Now with guards for "errors" like this:
external/skia/src/jumper/SkJumper_stages_8bit.cpp:240:50: error:
'memcpy' called with size bigger than buffer
case 12: memcpy(&v, src, 12*sizeof(T)); break;
This code is unreachable and generally removed by Clang's optimizer
anyway... as far as I can tell the code generation diff is arbitrary.
Change-Id: I6216567caaa6166f71258bd25343a09e93892a10
Reviewed-on: https://skia-review.googlesource.com/39961
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 08133583d5.
Reason for revert: Blocking Android Autoroller on compile error.
Original change's description:
> 8-bit jumper on armv8
>
> The GM diffs are all minor and what you'd expect.
>
> I did a quick performance sanity check, which also looks fine.
>
> $ out/ok bench rp filter:search=Modulate
> [blendmode_rect_Modulate] 30.2ms @0 32ms @95 32ms @100
> [blendmode_mask_Modulate] 12.6ms @0 12.6ms @95 14.5ms @100
> ~~~>
> [blendmode_rect_Modulate] 11.2ms @0 11.7ms @95 12.4ms @100
> [blendmode_mask_Modulate] 10.5ms @0 23.6ms @95 23.9ms @100
>
> This isn't even really the fastest we can make 8-bit go on ARMv8;
> it's actually much more natural to work de-interlaced there. Lots
> of room to follow up.
>
> Change-Id: I86b1099f6742bcb0b8b4fa153e85eaba9567cbf7
> Reviewed-on: https://skia-review.googlesource.com/39740
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,herb@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I71425d8b7fbb66be5cb50025871dd81358111da4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/39980
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
The GM diffs are all minor and what you'd expect.
I did a quick performance sanity check, which also looks fine.
$ out/ok bench rp filter:search=Modulate
[blendmode_rect_Modulate] 30.2ms @0 32ms @95 32ms @100
[blendmode_mask_Modulate] 12.6ms @0 12.6ms @95 14.5ms @100
~~~>
[blendmode_rect_Modulate] 11.2ms @0 11.7ms @95 12.4ms @100
[blendmode_mask_Modulate] 10.5ms @0 23.6ms @95 23.9ms @100
This isn't even really the fastest we can make 8-bit go on ARMv8;
it's actually much more natural to work de-interlaced there. Lots
of room to follow up.
Change-Id: I86b1099f6742bcb0b8b4fa153e85eaba9567cbf7
Reviewed-on: https://skia-review.googlesource.com/39740
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The SkiaRenderer in chromium is going to use the overdraw canvas and
filter for measuring overdraw. Move these headers out of src/ into
include/.
Bug: chromium:704285
Change-Id: I2abb1671b73e3d26552462cf700340a7e3b874f0
Reviewed-on: https://skia-review.googlesource.com/36160
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:6880
Change-Id: Ia8b94e52eec3feb5104d2351bf7a7e6f99101deb
Reviewed-on: https://skia-review.googlesource.com/26370
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
DAA is:
1. Much simpler than AAA.
SkScan_AAAPath.cpp is about 1700 lines.
SkScan_DAAPath.cpp is about 300 lines.
The whole DAA CL is only about 800 lines.
2. Much faster than AAA for complicated paths.
The speedup applies to GL backend (including ccpr)!
Here's the frame time of 'SampleApp --slide Chart' on macbook pro:
AAA-raster: 33ms
DAA-raster: 21ms
AAA-gl: 30ms
DAA-gl: 20ms
AAA-ccpr: 18ms
DAA-ccpr: 12ms
My linux desktop doesn't have SSE3 so the speedup is smaller
(~25% for Chart). I believe that DAA is so fast that I can enable
it for any paths (AAA is not enabled by default for complicated
paths because it is slow; hence our older supersampling scan
converter is used for stroking on Chart for AAA-xxx config.)
3. The SkCoverageDelta is suitable for threaded backend with
out-of-order concurrent scan conversion as commented in the source
code. Maybe we can also just send deltas to GPU.
4. Similar to most analytic path renderers, the quality is on the best
ground-truth level, unless there are intersections within a pixel.
The intersections look good to my eyes although theoretically that
could be arbitrary far from the ground truth (see my AAA slides).
5. For simple paths, such as circle, triangle, rrect, etc., DAA is
slower than AAA. But DAA is faster than our older supersampling
scan converter in most cases. As those simple paths usually don't
constitute the bottleneck of a picture (skp or svg), I strongly
recommend use DAA.
6. DAA also heavily favors blitMask so it may work quite well with
SkRasterPipeline and SkRasterPipelineBlitter.
Finally, please check https://skia-review.googlesource.com/c/22420/
which accelerate DAA by specializing blitCoverageDeltas for
SkARGB32_Blitter and SkARGB32_Black_Blitter. It brings a little(<5%)
speedup. But I couldn't figure out how to reduce the duplicate code
so I don't intend to land it.
Bug: skia:
Change-Id: I3b7ed6a727447922e645b1acb737a506e7c09a4c
Reviewed-on: https://skia-review.googlesource.com/19666
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This is mostly dead code.
In order to make it truly dead, we need to opt drawing unpremul images
into SkRasterPipelineBlitter. They had been handled by
SkLinearBitmapPipeline, but can't be draw by SkBitmapProcLegacyShader.
Drawing unpremul images is tested by the GM all_variants_8888, which
gave us trouble last time around (serialize-8888 drew right, 8888 wrong)
but now draws fine. I think this was probably also the root of the
revert, drawing some unpremul image in Chrome's tests somewhere.
Change-Id: I453f9df44ade807316935921cbae82961e2f08aa
Reviewed-on: https://skia-review.googlesource.com/24862
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Debian9-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Bug: skia:
Change-Id: If6f0d0a57463bf99a66d674e65a62ce3931d0116
Reviewed-on: https://skia-review.googlesource.com/24644
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit 27b3d272a8.
Reason for revert: guard has landed in android
Original change's description:
> Revert "Experimental blur code with 32 bit fix."
>
> This reverts commit d4b2c537d0.
>
> Reason for revert: speculative fix for android-roll
>
> java.lang.AssertionError: expected:<0> but was:<255>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at android.graphics.cts.BlurMaskFilterTest.verifyColor(BlurMaskFilterTest.java:79)
> at android.graphics.cts.BlurMaskFilterTest.verifyQuadrants(BlurMaskFilterTest.java:72)
> at android.graphics.cts.BlurMaskFilterTest.testBlurMaskFilter(BlurMaskFilterTest.java:56)
>
> Original change's description:
> > Experimental blur code with 32 bit fix.
> >
> > This uses a new method of blurring that runs the three
> > passes of the box filter in a single pass. This implementation
> > currently only does 1x1 pixel at a time, but it should be simple
> > to expand to 4x4 pixels at a time.
> >
> > On the blur_10_normal_high_quality benchmark, the new is 7% faster
> > than the old code. For the blur_100.50_normal_high_quality
> > benchmark, the new code is 11% slower.
> >
> > Bug: skia:
> > Change-Id: I847270906b0ceac1dfbf43ab5446756689ef660f
> > Reviewed-on: https://skia-review.googlesource.com/22700
> > Reviewed-by: Mike Reed <reed@google.com>
> > Commit-Queue: Herb Derby <herb@google.com>
>
> TBR=herb@google.com,reed@google.com
>
> Change-Id: Ie84f6bf8872cae08c06d679f0c2f2e6c3d8a02a2
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:
> Reviewed-on: https://skia-review.googlesource.com/22880
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=herb@google.com,reed@google.com
Change-Id: I393d1c05f83ccf98137201bc7b4e7d8e8b0e8742
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/23121
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This reverts commit d4b2c537d0.
Reason for revert: speculative fix for android-roll
java.lang.AssertionError: expected:<0> but was:<255>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at android.graphics.cts.BlurMaskFilterTest.verifyColor(BlurMaskFilterTest.java:79)
at android.graphics.cts.BlurMaskFilterTest.verifyQuadrants(BlurMaskFilterTest.java:72)
at android.graphics.cts.BlurMaskFilterTest.testBlurMaskFilter(BlurMaskFilterTest.java:56)
Original change's description:
> Experimental blur code with 32 bit fix.
>
> This uses a new method of blurring that runs the three
> passes of the box filter in a single pass. This implementation
> currently only does 1x1 pixel at a time, but it should be simple
> to expand to 4x4 pixels at a time.
>
> On the blur_10_normal_high_quality benchmark, the new is 7% faster
> than the old code. For the blur_100.50_normal_high_quality
> benchmark, the new code is 11% slower.
>
> Bug: skia:
> Change-Id: I847270906b0ceac1dfbf43ab5446756689ef660f
> Reviewed-on: https://skia-review.googlesource.com/22700
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
TBR=herb@google.com,reed@google.com
Change-Id: Ie84f6bf8872cae08c06d679f0c2f2e6c3d8a02a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/22880
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This uses a new method of blurring that runs the three
passes of the box filter in a single pass. This implementation
currently only does 1x1 pixel at a time, but it should be simple
to expand to 4x4 pixels at a time.
On the blur_10_normal_high_quality benchmark, the new is 7% faster
than the old code. For the blur_100.50_normal_high_quality
benchmark, the new code is 11% slower.
Bug: skia:
Change-Id: I847270906b0ceac1dfbf43ab5446756689ef660f
Reviewed-on: https://skia-review.googlesource.com/22700
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit d96ed9d0de.
Reason for revert: dm crashing
https://luci-milo.appspot.com/swarming/task/374d82c1d1263910/steps/symbolized_dm/0/stdout
Likely culprit:
unit test BlurDrawing
Stack trace:
/mnt/pd0/s/w/ir/out/Debug/dm(+0x2440eb) [0x568770eb]
linux-gate.so.1(__kernel_sigreturn+0) [0xf7714ca0]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK16SkMaskBlurFilter11blurOneScanENS_10FilterInfoEPKhjS2_PhjS3_+0x236) [0x5766301e]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK16SkMaskBlurFilter4blurERK6SkMaskPS0_+0x285) [0x57663491]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZN10SkBlurMask7BoxBlurEP6SkMaskRKS0_f11SkBlurStyle13SkBlurQualityP8SkIPointb+0x5c) [0x5720d48e]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK20SkBlurMaskFilterImpl10filterMaskEP6SkMaskRKS0_RK8SkMatrixP8SkIPoint+0x67) [0x5720e427]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK20SkBlurMaskFilterImpl17filterRectsToNineEPK6SkRectiRK8SkMatrixRK7SkIRectPN12SkMaskFilter9NinePatchE+0x579) [0x5721a247]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK12SkMaskFilter10filterPathERK6SkPathRK8SkMatrixRK12SkRasterClipP9SkBlitterN11SkStrokeRec9InitStyleE+0xf6) [0x5706c2bc]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK6SkDraw11drawDevPathERK6SkPathRK7SkPaintbP9SkBlitterb+0x1bb) [0x57034f1b]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNK6SkDraw8drawPathERK6SkPathRK7SkPaintPK8SkMatrixbbP9SkBlitter+0x47f) [0x57035dd3]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZN14SkBitmapDevice8drawPathERK6SkPathRK7SkPaintPK8SkMatrixb+0x6e) [0x56f937fc]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZN8SkCanvas10onDrawPathERK6SkPathRK7SkPaint+0x39d) [0x56fb12e5]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZN8SkCanvas8drawPathERK6SkPathRK7SkPaint+0x18) [0x56fad926]
/mnt/pd0/s/w/ir/out/Debug/dm(+0x3f71b3) [0x56a2a1b3]
/mnt/pd0/s/w/ir/out/Debug/dm(+0x2450bd) [0x568780bd]
/mnt/pd0/s/w/ir/out/Debug/dm(+0x2450fb) [0x568780fb]
/mnt/pd0/s/w/ir/out/Debug/dm(+0xae53e7) [0x571183e7]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZNKSt8functionIFvvEEclEv+0x20) [0x569f98de]
/mnt/pd0/s/w/ir/out/Debug/dm(_ZN12SkThreadPool4LoopEPv+0x298) [0x57045b2f]
/mnt/pd0/s/w/ir/out/Debug/dm(+0xbbd92c) [0x571f092c]
/lib/i386-linux-gnu/libpthread.so.0(+0x627a) [0xf76e827a]
/lib/i386-linux-gnu/libc.so.6(clone+0x66) [0xf70ecb56]
Segmentation fault
Original change's description:
> Experimental blur code.
>
> This uses a new method of blurring that runs the three
> passes of the box filter in a single pass. This implementation
> currently only does 1x1 pixel at a time, but it should be simple
> to expand to 4x4 pixels at a time.
>
> On the blur_10_normal_high_quality benchmark, the new is 7% faster
> than the old code. For the blur_100.50_normal_high_quality
> benchmark, the new code is 11% slower.
>
> Change-Id: Iea37294abc7c27de5ad569adf8bc62df77eafd02
> Reviewed-on: https://skia-review.googlesource.com/21739
> Commit-Queue: Herb Derby <herb@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=herb@google.com,reed@google.com
Change-Id: I9e896c548d0a4cd3308d6a311c8bd16719a08a85
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/22421
Reviewed-by: Florin Malita <fmalita@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
