SkMatrix::setPolyToPoly() may fail to map degenerate values. Handle
this case explicitly, instead of assuming it never fails.
BUG=chromium:738746
TBR=
Change-Id: Ie1049b98f7e07ae5d6bdb706ba7b4a399388e5d8
Reviewed-on: https://skia-review.googlesource.com/21375
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Gaussian blur filter will interpolate value by using out of bounds
coords, which is 0. This makes it appears darker near the bounds in the
blurred images. There are two issues: 1) when downsampling and
upsampling, we should use GrTextureDomainEffect kClamp_Mode to clamp
the texture coords to the bounds; 2) during Gaussian blur, we need to
clamp to texture bounds.
BUG=622128
TEST=cc_unittests, GM image test & manual. Some test results can be found at:
https://bugs.chromium.org/p/chromium/issues/detail?id=622128#c49
Change-Id: I9283da1d91efb0da94a991f2d372e9f62c288bdc
Reviewed-on: https://skia-review.googlesource.com/20465
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This is all kind of silly... this is just a little bit of code that's
not really reachable, but there to satisfy compilers that can't figure
that out.
Change-Id: Ib39e8bf0fd26e28541cfad37c7ea135a30dbe85a
Reviewed-on: https://skia-review.googlesource.com/21365
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
- Separate graphic state objects for Stroke and Fill.
- SkPDFGraphicState::GetGraphicStateForPaint simplified.
- No more SkPDFGraphicState objects.Simplify SkPDFCanon.
All PDFs render the same. Most PDFs are slightly smaller, especially
those from captured web pages.
Change-Id: Id9605c1d7495645da558d5f378ba585cdc201bba
Reviewed-on: https://skia-review.googlesource.com/21343
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
From the bug it looks like a null fragment processors may be getting into the processor set. This CL tries to plug any gaps in our fragmentProcessor handling.
The only real substantive part to this CL is the addition of some "if (!fp) { return nullptr; }" blocks.
Everything else is just to add chokepoints for processor allocation.
Bug: 734076
Change-Id: I4952b1a05bc6690d5aa09de977fa6dc54c80338a
Reviewed-on: https://skia-review.googlesource.com/21267
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Speculative fix for decode failure
Bug: skia:6818
Change-Id: I7db0afb87f42cc8372782409cfe74fdb715f95f0
Reviewed-on: https://skia-review.googlesource.com/21362
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: I813fe71812ec65778b48b8b13f238b8df7b8f8cd
Reviewed-on: https://skia-review.googlesource.com/21360
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
It seems to be stable after upgrading to Debian 9.
Bug: skia:
Change-Id: I6c89f14748da177c9b0ede8da1da492564e66118
Reviewed-on: https://skia-review.googlesource.com/21361
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: I7df6434a5fc538bb070f02efd3e211e1f57aecb5
Reviewed-on: https://skia-review.googlesource.com/21268
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: I6611638097b473d719106c239012b5382d962941
Reviewed-on: https://skia-review.googlesource.com/21266
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: skia:6612
Change-Id: I569eae4643802a5f081da028bc21addeda48679b
Reviewed-on: https://skia-review.googlesource.com/21160
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Change-Id: I3dead53a30992edd032f16e6711b97bbf76a0e36
Reviewed-on: https://skia-review.googlesource.com/21261
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: Ie8a31ea8131c08d251a825622484342e3e174474
Reviewed-on: https://skia-review.googlesource.com/21207
Commit-Queue: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
In our current implementation of SkImageFilterCache, when the
removeInternal() function is called, the Value is removed, but their
corresponding keys are not always removed in SkImageFilter. That could
result in memory leak.
In this CL, we made changes such that the Value structure now keeps
a pointer to the SkImageFilter. Each time when the removeInternal()
is called, we ask the SkImageFilter to remove the associated keys.
Bug: 689740
Change-Id: I0807fa3581881ad1530536df5289e3976792281f
Reviewed-on: https://skia-review.googlesource.com/20960
Commit-Queue: Xida Chen <xidachen@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
A couple of annoyances here:
1) the prev vector_scale stage is not usable for masking, as NaN values can propagate through
=> switch to actual masking
2) for the outside case, we must select the min root when the gradient is flipped
=> split into two templated stages (_min, _max)
(I'm not convinced that we need to flip the gradient for RP at all; we can investigate later)
Change-Id: I0283812d613a53124f2987d1aea1f26e4533655e
Reviewed-on: https://skia-review.googlesource.com/21162
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Instead of rejecting all sprite blitters when there's a color filter,
just remove the old legacy color filter sprite blitters. The
SkRasterPipelineSpriteBlitter can still handle color filters... no need
to fall back to the general shader (gather) blitter.
Change-Id: Ib27f3e153612d0d904093da68223c2b862b17f63
Reviewed-on: https://skia-review.googlesource.com/21204
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
These can fall through to the SkRasterPipelineSpriteBlitter just fine.
Change-Id: I56f4f177475b233fd2d3352df1ecddc47be0d37d
Reviewed-on: https://skia-review.googlesource.com/21203
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 0e29c633fe.
Reason for revert: The layout tests have been suppressed in https://chromium-review.googlesource.com/c/553239/ - no need to revert
Bug: 737714
Original change's description:
> Revert "use blitMask for left/right edges in blur-nine"
>
> This reverts commit 3fe44544c9.
>
> Reason for revert: I believe this is the cause of the layout test regressions in crbug.com/737714
>
> Bug: 737714
>
> Original change's description:
> > use blitMask for left/right edges in blur-nine
> >
> > Seems about same speed for legacy blitter, but much faster for raster-pipeline
> >
> > Bug: skia:
> > Change-Id: I19be307c01a199e2477e045fb8c2cca7784564a5
> > Reviewed-on: https://skia-review.googlesource.com/20967
> > Commit-Queue: Mike Reed <reed@google.com>
> > Reviewed-by: Mike Klein <mtklein@chromium.org>
>
> TBR=mtklein@chromium.org,mtklein@google.com,fmalita@chromium.org,reed@google.com
>
> Change-Id: Id7be3ff779191175d91ebd51c7d275fd1104ae0d
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:
> Reviewed-on: https://skia-review.googlesource.com/21182
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=mtklein@chromium.org,mtklein@google.com,robertphillips@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I9f232e838bcad4e4cf0d8c7226d5e57a349e52be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 737714, skia:
Reviewed-on: https://skia-review.googlesource.com/21183
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 3fe44544c9.
Reason for revert: I believe this is the cause of the layout test regressions in crbug.com/737714
Bug: 737714
Original change's description:
> use blitMask for left/right edges in blur-nine
>
> Seems about same speed for legacy blitter, but much faster for raster-pipeline
>
> Bug: skia:
> Change-Id: I19be307c01a199e2477e045fb8c2cca7784564a5
> Reviewed-on: https://skia-review.googlesource.com/20967
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,mtklein@google.com,fmalita@chromium.org,reed@google.com
Change-Id: Id7be3ff779191175d91ebd51c7d275fd1104ae0d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/21182
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: skia:6781
Change-Id: Ife0896ab45a47910273353f1269f62dbeda67ba0
Reviewed-on: https://skia-review.googlesource.com/20986
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
When the focal point is on the edge of the end circle, the quadratic
equation devolves to linear. Add a stage to handle this case.
As a complication, this case can produce "degenerate" values:
1) t == NaN
2) R(t) < 0
For these, we're supposed to draw transparent black - which means
overwriting the color from the gradient stage. To support this, build
a 0/1 vector mask in the context, and apply it post-gradient-stage.
Change-Id: Ice4e3243abfd8c784bb810f6c310aed7a4ac7dc8
Reviewed-on: https://skia-review.googlesource.com/21111
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Klein <mtklein@google.com>
- Use clearMaskOnGraphicState()
- SkPDFGraphicState::MakeNoSmaskGraphicState now moved to only caller.
- Get rid of clunky SkPDFUtils::GetCachedT
Change-Id: If76a1e915fc31e3ce2654fbe620ff44c1820c0e7
Reviewed-on: https://skia-review.googlesource.com/21142
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Bug: skia:6612
Change-Id: I2920bb7b1aa3ebb021223ed6345f13f1f9c8bc24
Reviewed-on: https://skia-review.googlesource.com/21141
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
On Android it looks like we have:
stencilClip1
draw1
stencilClip2
draw2
where draw1 is being forward combined with draw2 b.c. they are both stencil clipped but it shouldn't b.c. they are different stencil clips.
Change-Id: Ia704d7ab869022a055eed0726e2b7fab8eaaf817
Reviewed-on: https://skia-review.googlesource.com/20977
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
