This is to support a Mock backend that passes non-rendering context unit tests and has minimal config support.
Change-Id: I57c3ad2d347659d14382a8a7cf53424633bd86c6
Reviewed-on: https://skia-review.googlesource.com/21534
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:
Change-Id: Iddeeb91b378bdb61d200070d8faa3610299ab733
Reviewed-on: https://skia-review.googlesource.com/21533
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Bug: skia:
Change-Id: I641b206fc3bc19ac190ad94ee755ab9e1caab9b3
Reviewed-on: https://skia-review.googlesource.com/21341
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
... faster and more accurate than using SkTableColorFilter
todo: update blink after this lands
Bug:737981
Change-Id: I55b5c60dd23b9d2cbe9d60f83c74be1a8f3dcfcf
Reviewed-on: https://skia-review.googlesource.com/21368
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This makes it trivial to copy/paste into spreadsheets for sorting/diffing
Bug: skia:
Change-Id: I02c920e2b8be8f59270da9fb9bb3e6763987e0bc
Reviewed-on: https://skia-review.googlesource.com/21378
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
We have removed support for drawing Index8, so stop testing it in DM.
Bug: skia: 6828
Change-Id: Ib2c4d3ebd371be704151a9f956c0ca2aaf2926a6
Reviewed-on: https://skia-review.googlesource.com/21525
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: skia:
Change-Id: I25d4f4eeb3d06f3e2b64aad652ef91743494755a
Reviewed-on: https://skia-review.googlesource.com/21528
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Mike Reed <reed@google.com>
my tests run ~14% faster.
- Split out gradient shaders from image shaders. new compilation
unit: SkPDFGradientShader
- Common functions InverseTransformBBox and PopulateTilingPatternDict
moved to SkPDFUtils
- Split SkPDFShader::State into image and gradient structures.
- SkPDFCanon is now a simpler structure, with no logic of its own.
I am considering just moving all of its fields into SkPDFDocument
- SkPDFShader::State (the image/fallback shader) now is POD, making
the use of a hashmap for canonicalization straightforward.
Formerly, we used a linear search.
- Do not bother trying to canonicalize the falback image shader.
- SkPDFGradientShader::Key is not POD; comparison of two objects
requires looking at the contents of two variable-sized arrays.
We now pre-calculate the hash of the arrays using SkOpts::hash and
store a hash for the object in the fHash field.
Using that hash, we can now canonicalize using a hashmap instead
of a linar search!
- several static functions renamed to follow style guidelines
- stop using codeFunction function pointer; I find that less
clear than it could be.
- operator==() for SkPDFShader::State and SkPDFGradientShader::Key is
now much simpler and can now be inlined.
- SkArrayEqual template in SkPDFUtils.h
No change to PDF output.
BUG=skia:3585
Change-Id: I354ad1b600be6d6749abccb58d13db257370bc0b
Reviewed-on: https://skia-review.googlesource.com/21376
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Similar to SkShaderBase::makeContext(), catch this condition and bail
early.
BUG=chromium:738682
Change-Id: I4c7a2036bed8ab8699023c4f8f3bc2161de0c41d
Reviewed-on: https://skia-review.googlesource.com/21521
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This reverts commit fe11e458b0.
Reason for revert: android roll failed, even with newer images:
junit.framework.AssertionFailedError: 80 dpi: totalDiffPixelCount is 2
at junit.framework.Assert.fail(Assert.java:50)
at android.graphics.drawable.cts.DrawableTestUtils.compareImages(DrawableTestUtils.java:193)
at android.graphics.drawable.cts.BitmapDrawableTest.compareOrSave(BitmapDrawableTest.java:629)
at android.graphics.drawable.cts.BitmapDrawableTest.verifyPreloadDensityInner(BitmapDrawableTest.java:598)
at android.graphics.drawable.cts.BitmapDrawableTest.testPreloadDensity(BitmapDrawableTest.java:556)
Original change's description:
> enable new tiling for android
>
> android roll will need to be coordinated w/
> https://googleplex-android-review.git.corp.google.com/#/c/2483600/
>
> Bug: skia:
> Change-Id: Iee6d6cd246f2e5b64f24440a17791821c8fb2f94
> Reviewed-on: https://skia-review.googlesource.com/21369
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=djsollen@google.com,reed@google.com
Change-Id: Ic8cd056d0737a817d558cc1de9d90d8d334d0ec1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/21522
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
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>
