aboutsummaryrefslogtreecommitdiffhomepage
path: root/tests/ImageFilterTest.cpp
Commit message (Collapse)AuthorAge
...
* Remove SK_SUPPORT_LEGACY_DEEPFLATTENING.Gravatar mtklein2014-12-01
| | | | | | | | | | | | This was needed for pictures before v33, and we're now requiring v35+. Will follow up with the same for skia/ext/pixel_ref_utils_unittest.cc BUG=skia: Committed: https://skia.googlesource.com/skia/+/52c293547b973f7fb5de3c83f5062b07d759ab88 Review URL: https://codereview.chromium.org/769953002
* Revert of Remove SK_SUPPORT_LEGACY_DEEPFLATTENING. (patchset #1 id:1 of ↵Gravatar mtklein2014-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/769953002/) Reason for revert: Breaks canary builds. Will reland after the Chromium change lands. Original issue's description: > Remove SK_SUPPORT_LEGACY_DEEPFLATTENING. > > This was needed for pictures before v33, and we're now requiring v35+. > > Will follow up with the same for skia/ext/pixel_ref_utils_unittest.cc > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/52c293547b973f7fb5de3c83f5062b07d759ab88 TBR=reed@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/768183002
* Remove SK_SUPPORT_LEGACY_DEEPFLATTENING.Gravatar mtklein2014-12-01
| | | | | | | | | | This was needed for pictures before v33, and we're now requiring v35+. Will follow up with the same for skia/ext/pixel_ref_utils_unittest.cc BUG=skia: Review URL: https://codereview.chromium.org/769953002
* Disable LCD text explicitly in SkPictureImageFilter::onFilterImage()Gravatar fmalita2014-11-20
| | | | | | | | | | | As an intermediate fix for https://code.google.com/p/skia/issues/detail?id=3142, we can use a non-public SkCanvas constructor and force-disable LCD text. BUG=skia:3142 R=reed@google.com,senorblanco@google.com Review URL: https://codereview.chromium.org/725243004
* Fix bounds computation of all 0-input filters.Gravatar senorblanco2014-10-29
| | | | | | | | | | | The SkRectShaderImageFilter had the same bug as previously fixed for SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste the implementation, this change makes all filters with 0 inputs return their source bounds, instead of returning false. BUG=427251 Review URL: https://codereview.chromium.org/681643003
* Revert of Fix bounds computation of all 0-input filters. (patchset #2 ↵Gravatar hcm2014-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | id:20001 of https://codereview.chromium.org/681643003/) Reason for revert: try again Original issue's description: > Fix bounds computation of all 0-input filters. > > The SkRectShaderImageFilter had the same bug as previously fixed for > SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste > the implementation, this change makes all filters with 0 inputs return > their source bounds, instead of returning false. > > BUG=427251 > > Committed: https://skia.googlesource.com/skia/+/ba036cc82b5a543a13cafd11a19ba0e3087fca38 TBR=bsalomon@google.com,senorblanco@chromium.org NOTREECHECKS=true NOTRY=true BUG=427251 Review URL: https://codereview.chromium.org/678273002
* Fix bounds computation of all 0-input filters.Gravatar senorblanco2014-10-27
| | | | | | | | | | | The SkRectShaderImageFilter had the same bug as previously fixed for SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste the implementation, this change makes all filters with 0 inputs return their source bounds, instead of returning false. BUG=427251 Review URL: https://codereview.chromium.org/681643003
* Adding an option to render only the shadow in SkDropShadowImageFilterGravatar sugoi2014-10-23
| | | | | | | | This is basically how blink uses the filter. Currently, I can't use it for "ShadowOnly" mode with the filter at all, but instead of copying the code and risking to have the codepaths diverge, I'm simply going to add the option here. BUG=skia: Review URL: https://codereview.chromium.org/646213004
* Sanitize SkMatrixConvolutionImageFilter creation params.Gravatar senorblanco2014-09-29
| | | | | | | | | | | Apply the same memory limit in the Create() function that we do when deserializing. R=reed@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/610723002
* Introduce Props to surface (patchset #27 id:520001 of ↵Gravatar reed2014-09-22
| | | | | | | | | | | | https://codereview.chromium.org/551463004/)" This reverts commit 29c857d0f3a1cb837f73406eeb6ba9771879b5e7. TBR= Author: reed@google.com Review URL: https://codereview.chromium.org/588143004
* Revert of introduce Props to surface (patchset #27 id:520001 of ↵Gravatar reed2014-09-21
| | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/551463004/) Reason for revert: Broke call site in WebKit Original issue's description: > introduce Props to surface (work in progress) > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/3716fd067a5621bb94a6cb08d72afec8bf3aceda R=robertphillips@google.com, bsalomon@google.com, jvanverth@google.com, bungeman@google.com, fmalita@google.com, vangelis@chromium.org, reed@google.com TBR=bsalomon@google.com, bungeman@google.com, fmalita@google.com, jvanverth@google.com, reed@google.com, robertphillips@google.com, vangelis@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Author: reed@chromium.org Review URL: https://codereview.chromium.org/583773004
* introduce Props to surface (work in progress)Gravatar reed2014-09-21
| | | | | | | | | BUG=skia: R=robertphillips@google.com, bsalomon@google.com, jvanverth@google.com, bungeman@google.com, fmalita@google.com, vangelis@chromium.org, reed@chromium.org Author: reed@google.com Review URL: https://codereview.chromium.org/551463004
* Allow negative values in SkBlurImageFilter sigma.Gravatar senorblanco2014-09-09
| | | | | | | | | | | | | | | | | | | | | There are two ways negative sigma values may occur: in the original filter parameters, or after multiplication by a negative scaling CTM. The former case is invalid according to the spec, so we continue to check for it at validation time. In the latter case, we should interpret it as a horizontal flip in the kernel pixel access, and simply take the absolute value (since the filter kernel is symmetric). Also refactor all this logic into a single place for the CPU, GPU and onFilterBounds() paths. BUG=https://code.google.com/p/chromium/issues/detail?id=409602 R=sugoi@google.com, reed@google.com, sugoi@chromium.org Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/555603002
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* Try out scalar picture sizesGravatar robertphillips2014-08-29
| | | | | | | | | | This paves the way for removing the 'fTile' parameter from SkPictureShader (although that should be a different CL). If we like this we could also move to providing an entire cull SkRect. R=reed@google.com, mtklein@google.com, fmalita@google.com, fmalita@chromium.org Author: robertphillips@google.com Review URL: https://codereview.chromium.org/513983002
* Fix recursive computation of filter bounds for drop shadow,Gravatar senorblanco2014-08-25
| | | | | | | | | | | | | | | | | | | | | | morphology, blur. [Reland with fixed tests.] Because we're computing "backwards" from a clip rect of destination pixels to be filled to the required source pixels, we should use tail recursion rather than head recursion in onFilterBounds(). This actually only makes a difference for drop-shadow, where the computation is non-commutative. Blur and morphology commute, but I moved them to tail recursion anyway for clarity (so all onFilterBounds use tail recursion). BUG=skia: R=bsalomon@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/481273005
* Revert of Fix recursive computation of filter bounds for drop shadow, ↵Gravatar djsollen2014-08-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #1 of https://codereview.chromium.org/481273005/) Reason for revert: This CL is currently breaking the Win7 and Win8 bots on some of the new tests (in DM). Original issue's description: > Fix recursive computation of filter bounds for drop shadow, > morphology, blur. > > Because we're computing "backwards" from a clip rect of destination > pixels to be filled to the required source pixels, we should use tail > recursion rather than head recursion in onFilterBounds(). > > This actually only makes a difference for drop-shadow, where > the computation is non-commutative. Blur and morphology commute, but I > moved them to tail recursion anyway for clarity (so all onFilterBounds > use tail recursion). > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/28648fe4a69b0cee8df42b5966e4e645c3aabefb R=bsalomon@google.com, senorblanco@chromium.org TBR=bsalomon@google.com, senorblanco@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Author: djsollen@google.com Review URL: https://codereview.chromium.org/504773003
* Fix recursive computation of filter bounds for drop shadow,Gravatar senorblanco2014-08-25
| | | | | | | | | | | | | | | | | | | | morphology, blur. Because we're computing "backwards" from a clip rect of destination pixels to be filled to the required source pixels, we should use tail recursion rather than head recursion in onFilterBounds(). This actually only makes a difference for drop-shadow, where the computation is non-commutative. Blur and morphology commute, but I moved them to tail recursion anyway for clarity (so all onFilterBounds use tail recursion). BUG=skia: R=bsalomon@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/481273005
* Fix saveLayer() with a pixel-moving filter vs SkBBoxHierarchyRecord / ↵Gravatar mtklein2014-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | SkRecordDraw In SkBBoxHierarchyRecord: Since the bounds we pass to saveLayer are in the pre-filtering coordinate space, they aren't correct for determining the actual device pixels touched by the saveLayer in this case. The easiest fix for now is to pass the clip bounds, since the final draw done in restore() will never draw outside the clip. In SkRecordDraw: We do adjust the bounds passed to saveLayer, so we just need to make sure that when we're using a paint that may affect transparent black, we ignore the calculated bounds of draw ops and use the clip intersected with those adjusted bounds. See originally crrev.com/497773002 BUG=skia: R=reed@google.com, senorblanco@chromium.org, junov@chromium.org, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/496963003
* Simplify flattening to just write enough to call the ↵Gravatar reed2014-08-21
| | | | | | | | | | | | | | | | | | factory/public-constructor for the class. We want to *not* rely on private constructors, and not rely on calling through the inheritance hierarchy for either flattening or unflattening(CreateProc). Refactoring pattern: 1. guard the existing constructor(readbuffer) with the legacy build-flag 2. If you are a instancable subclass, implement CreateProc(readbuffer) to create a new instances from the buffer params (or return NULL). If you're a shader subclass 1. You must read/write the local matrix if your class accepts that in its factory/constructor, else ignore it. R=robertphillips@google.com, mtklein@google.com, senorblanco@google.com, senorblanco@chromium.org, sugoi@chromium.org Author: reed@google.com Review URL: https://codereview.chromium.org/395603002
* Move SkReadBuffer.h and SkReader32.h out of include.Gravatar halcanary2014-08-19
| | | | | | | | | | Committed: https://skia.googlesource.com/skia/+/2a51d7c74cec217195f861677de8998b382b39e4 R=mtklein@google.com, reed@google.com Author: halcanary@google.com Review URL: https://codereview.chromium.org/481053002
* Revert "Move SkReadBuffer.h and SkReader32.h out of include."Gravatar halcanary2014-08-18
| | | | | | | | | | | | | | This reverts commit 2a51d7c74cec217195f861677de8998b382b39e4. Breaking Blink NOTRY=true R=bungeman@google.com TBR=bungeman@google.com Author: halcanary@google.com Review URL: https://codereview.chromium.org/472303006
* Move SkReadBuffer.h and SkReader32.h out of include.Gravatar halcanary2014-08-18
| | | | | | | | R=mtklein@google.com, reed@google.com Author: halcanary@google.com Review URL: https://codereview.chromium.org/481053002
* Intersect SkPictureImageFilter bounds against clip bounds.Gravatar senorblanco2014-07-30
| | | | | | | | | | | | | | Intersect SkPictureImageFilter bounds against clip bounds to avoid unnecessary processing. This is how the other filters work (via applyCropRect()), but SkPictureImageFilter maintains its own crop. BUG=skia: R=bsalomon@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/428263003
* Implement a persistent uniqueID-based cache for SkImageFilter.Gravatar senorblanco2014-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a unique ID to SkImageFilter, and use it as part of a persistent cache of image-filtered results. This is used for caching frame-to-frame coherent filters. We also keep track of which filter subtrees do not reference the src input, and use a GenID of zero for the src input in that case. That way, subtrees which are not dependent on the filter input can be cached independently of it. This gives approximately a 4X speedup on letmespellitoutforyou.com/samples/svg/filter_terrain.svg on Z620 and Nexus10. The cache key consists of the uniqueID of the filter, the clip bounds, the CTM and the genID of the input bitmap. Since this does not yet handle the case where the input primitives (and part of the resulting filter tree) are unchanged, we have to keep around the external cache for that painting case. When the work to cache unchanging input primitives is done, the old cache can be removed, and the new UniqueIDCache will be renamed to Cache. R=bsalomon@google.com, mtklein@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/414483003
* Fix for saveLayer() with filters vs. the BBox Hierarchy.Gravatar senorblanco2014-07-14
| | | | | | | | | | | | | | | | | | | | When building acceleration structures for SkPicture, we must transform the primitive's bounds not only by its own SkPaint, but by the paints of any saveLayer()s currently active above it. We do this by pushing the SkPaint onto a stack on saveLayer(), and popping them on restore(). We also push a NULL paint in save(), so that the pushes and pops are balanced. BUG=skia:2734 R=mtklein@google.com, reed@google.com, robertphillips@google.com Committed: https://skia.googlesource.com/skia/+/6ca0b6a46cbe9bef3e2b9b9db813ec864efd62de Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/380373003
* Revert "Fix for saveLayer() with filters vs. the BBox Hierarchy." andGravatar senorblanco2014-07-14
| | | | | | | | | | | | | | | | "resizeimagefiler is ok with a BBH now". This reverts commits 6ca0b6a46cbe9bef3e2b9b9db813ec864efd62de and 8fa73202eaffbd7591ee218ad452b9afde81f505. Apparently causing problems in SKP playback. R=mtklein@google.com, robertphillips@google.com TBR=mtklein, robertphillips BUG=skia: Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/381353005
* Fix for saveLayer() with filters vs. the BBox Hierarchy.Gravatar senorblanco2014-07-11
| | | | | | | | | | | | | | | | | | When building acceleration structures for SkPicture, we must transform the primitive's bounds not only by its own SkPaint, but by the paints of any saveLayer()s currently active above it. We do this by pushing the SkPaint onto a stack on saveLayer(), and popping them on restore(). We also push a NULL paint in save(), so that the pushes and pops are balanced. BUG=skia:2734 R=mtklein@google.com, reed@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/380373003
* Revert "Remove ability for Release code to call getRefCnt() or getWeakRefCnt()."Gravatar Mike Klein2014-07-09
| | | | | | | | This reverts commit 4ae94ffce5ecf1b71cb5e295b68bf4ec9e697443. BUG=skia: Review URL: https://codereview.chromium.org/382523002
* Clean up SkImageFilter constructors.Gravatar senorblanco2014-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that all creation of SkImageFilters goes through factory Create() methods, there's no real reason for the convenience constructors. Some SkImageFilter subclasses which actually have zero DAG-able inputs were passing NULL to the superclass constructor. This actually means 1 input, with a NULL value, not zero inputs. This becomes more relevant for the upcoming cache infrastructure, where this indicates that the filter will use its src input, where in fact some of these filters do not (they are image generators only). Limiting SkImageFilter to a single constructor resolves this ambiguity. Along the way, I removed all of the default parameters to the constructors, since the Create methods always call them with the full argument list. BUG=skia: R=reed@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/376953003
* Remove ability for Release code to call getRefCnt() or getWeakRefCnt().Gravatar mtklein2014-07-08
| | | | | | | | | | | | | | | | | These getRefCnt() methods are not thread safe, so Skia code should not be calling them. unique() is fine. SkDEBUG code (SkASSERTs) can still call getRefCnt() / getWeakRefCnt(). This adds tools/RefCntIs.{h,cpp}, which lets tests make their assertions in both debug and release modes. BUG=skia:2726 R=senorblanco@chromium.org, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/378643003
* Fix SkColorFilterImageFilter matrix optimization.Gravatar senorblanco2014-07-03
| | | | | | | | | | | | | The order of matrices passed to multiplication was wrong (apparently, this optimization was only being tested with matrices which commute). See Chrome bug http://crbug.com/378362 R=sugoi@chromium.org Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/371523002
* Remove SkBicubicImageFilter, and all related tests.Gravatar senorblanco2014-06-25
| | | | | | | | | | | | | Now that we have SkResizeImageFilter, and the bicubic resizing is part of skia proper, there's no need for a specialized image filter. BUG=skia: R=bsalomon@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/357793002
* Preprend Test to test function name generated by DEF_TEST() macro.Gravatar tfarina2014-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | That way when declaring a test with DEF_TEST() macro, you don't have to uniquify the test name because it might colide with the class it is being testing. For example, if you are testing SkBase64 and do: DEF_TEST(SkBase64, reporter) { } That will generate an error because the macro will declare a function named SkBase64 which colides with the type SkBase64. By adding Test to the function name we avoid this problem. Fixed the entries found with the following command line: $ git grep "Test, r" | grep DEF BUG=None TEST=make tests && out/Debug/tests R=mtklein@google.com Author: tfarina@chromium.org Review URL: https://codereview.chromium.org/345753007
* Alter SkCanvas::drawPicture (devirtualize, take const SkPicture, take pointer)Gravatar robertphillips2014-06-04
| | | | | | | | R=reed@google.com, bsalomon@google.com, mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/313613004
* Allow SkPictureImageFilter to be serialized when not run cross-process.Gravatar senorblanco@chromium.org2014-05-30
| | | | | | | | | | | | | | | | | | | | | | Picture serialization is not yet hardened, but it turns out we do need serialization of SkPictureImageFilter for deferred SVG-on-SVG filters, since the SkPaints (and thus the SkImageFilters) are serialized by SkPictureRecord. However, deferred filters are always drawn in the same process, so we can safely serialize them in this case. We do this by turning the compile-time check for SK_ALLOW_PICTUREIMAGEFILTER_SERIALIZATION to a runtime check for isCrossProcess(). The image filter fuzzer sample was also modified to enable fuzzing of basic picture image filters (the code had rotted a bit, being behind an #ifdef that no one sets). BUG=375162 R=sugoi@google.com Review URL: https://codereview.chromium.org/311443003 git-svn-id: http://skia.googlecode.com/svn/trunk@15008 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement SkPictureImageFilter bounds computation.Gravatar senorblanco@chromium.org2014-05-30
| | | | | | | | | | | | | SkPictureImageFilter::onFilterBounds() was unimplemented, causing incorrect results for SVG filters and impl-side painting (see Chrome bug https://code.google.com/p/chromium/issues/detail?id=375162). BUG=skia: R=reed@google.com Review URL: https://codereview.chromium.org/306733003 git-svn-id: http://skia.googlecode.com/svn/trunk@15003 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fix filter bounds computation for SkOffsetImageFilter.Gravatar senorblanco@chromium.org2014-05-28
| | | | | | | | | | | | SkOffsetImageFilter::onFilterBounds() was not recursing into its input filter when computing bounds. BUG=374556 R=junov@chromium.org Review URL: https://codereview.chromium.org/304743003 git-svn-id: http://skia.googlecode.com/svn/trunk@14928 2bbb7eff-a529-9590-31e7-b0007b416f81
* Some small cleanups for image filter code.Gravatar senorblanco@chromium.org2014-05-07
| | | | | | | | | | | Use the 2-param flavour of mapVector instead of the 3-param, where possible. Add an SkMatrixImageFilter test case to the tiling unit test. R=junov@chromium.org Review URL: https://codereview.chromium.org/277543002 git-svn-id: http://skia.googlecode.com/svn/trunk@14630 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fix for SkDisplacementMap::onFilterBounds().Gravatar senorblanco@chromium.org2014-05-07
| | | | | | | | | | | | | Two problems: we were not applying the CTM to the scale parameter when modifying clip bounds, and the recursion for onFilterBounds() must be done in the reverse order. BUG=370914 R=junov@chromium.org Review URL: https://codereview.chromium.org/272643003 git-svn-id: http://skia.googlecode.com/svn/trunk@14627 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fix for empty saveLayer() with a filter which affects transparent black.Gravatar senorblanco@chromium.org2014-05-06
| | | | | | | | | | | | | | | | | | | | | If an saveLayer()/restore() is recorded, tilegrid/rtree will cull them out and not draw anything. This is correct for most cases, but if the paint in the saveLayer() is one that affects transparent black (e.g., it contains a color filter or image filter which affects transparent black), this is incorrect: the filter should be applied. Fixed by adding a no-op between the saveLayer() and restore(), and adding a bbox node pointing at that node with the saveLayer()'s bounds. This exposed a bug in SkPictureRecord.cpp's match(), where it would assert if the NOOP was the last op seen. Fixed with an early-out before calling peek_op_and_size(). BUG=skia:2254 Review URL: https://codereview.chromium.org/262363007 git-svn-id: http://skia.googlecode.com/svn/trunk@14604 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fix for SkMatrixConvolutionImageFilter with large borders.Gravatar senorblanco@chromium.org2014-05-02
| | | | | | | | | | | Intersect the requested processing rect with the destination bounds. R=junov@chromium.org Review URL: https://codereview.chromium.org/267863004 git-svn-id: http://skia.googlecode.com/svn/trunk@14543 2bbb7eff-a529-9590-31e7-b0007b416f81
* Add a fix for a spurious assert in SkMatrixConvolutionImageFilter.Gravatar senorblanco@chromium.org2014-05-01
| | | | | | | | | | | | | | | When matrix convolution processes border pixels with zero width, it asserts in getAddr32() with an invalid x coordinate. The assert is harmless, since the returned pointer is never accessed (the next line is a loop from left to right, which does nothing, since left == right). However, the fix is simple: early out on an empty rect before entering the outer loop. R=sugoi@chromium.org Review URL: https://codereview.chromium.org/265693005 git-svn-id: http://skia.googlecode.com/svn/trunk@14497 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement bounds traversals for tile and matrix convolution filters.Gravatar senorblanco@chromium.org2014-04-29
| | | | | | | | | | | | | | | | | | Add a new GM that exercises tiled drawing all pixel-moving filters (and some non-pixel-moving ones) and compares it against non-tiled drawing of the same filters. Fixing this test revealed that tile and matrix convolution filters had no onFilterBounds() traversals (test-driven development FTW). Tile requires (conservatively) the bounds to include the whole source rect, since it may end up in the result. Matrix convolution requires the bounds to be offset by the kernel size and target. R=reed@google.com BUG=skia: Review URL: https://codereview.chromium.org/258243005 git-svn-id: http://skia.googlecode.com/svn/trunk@14432 2bbb7eff-a529-9590-31e7-b0007b416f81
* Staging for cleanup of SkPicture-related headersGravatar robertphillips@google.com2014-04-18
| | | | | | | | https://codereview.chromium.org/243173002 git-svn-id: http://skia.googlecode.com/svn/trunk@14258 2bbb7eff-a529-9590-31e7-b0007b416f81
* Reduce internal explicit SaveFlags usage.Gravatar commit-bot@chromium.org2014-04-18
| | | | | | | | | | | | | Most of these are either redundant/defaults or (hopefully) unnecessarily specific. R=reed@google.com, robertphillips@google.com Author: fmalita@chromium.org Review URL: https://codereview.chromium.org/241453003 git-svn-id: http://skia.googlecode.com/svn/trunk@14253 2bbb7eff-a529-9590-31e7-b0007b416f81
* Staged removal of SkPicture-derived classesGravatar commit-bot@chromium.org2014-04-17
| | | | | | | | | | | | | | This CL removes the SkPicture-derived classes (with a flag to keeps clients working). In the process it also lightens the recording factory function so it is no longer ref counted). The only interesting bits are in SkPicture* and Sk*Picture.* R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/238273012 git-svn-id: http://skia.googlecode.com/svn/trunk@14251 2bbb7eff-a529-9590-31e7-b0007b416f81
* Retract SkPicture::kOptimizeForClippedPlayback_RecordingFlag from public APIGravatar commit-bot@chromium.org2014-04-16
| | | | | | | | | | | | | | | | | | This CL sets the stage for retracting the SkPicture::kOptimizeForClippedPlayback_RecordingFlag flag from the public API (more work needs to be done in Blink & Chrome). In the new world the only way to set this flag (and thus instantiate an SkPicture-derived class) is by passing a factory to the SkPictureRecorder class. This is to get all clients always using factories so that we can then change the factory call used (i.e., so the factory just creates a BBH) and do away with the SkPicture-derived classes. BUG=skia:2315 R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/239703006 git-svn-id: http://skia.googlecode.com/svn/trunk@14221 2bbb7eff-a529-9590-31e7-b0007b416f81
* split SkPictureRecorder out of SkPictureGravatar robertphillips@google.com2014-04-13
| | | | | | | | https://codereview.chromium.org/214953003/ git-svn-id: http://skia.googlecode.com/svn/trunk@14171 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement intra-frame cacheing in image filters.Gravatar commit-bot@chromium.org2014-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When image filters are processed within Skia, they simply do a blind recursion. This has the side-effect of turning the DAG into a tree. I.e., nodes visited more than once during the traversal will be processed more than once. This change implements a very simple cacheing scheme: a cache is created before traversing the DAG, and handed into the processing traversal. Before recursing into a child in SkImageFilter::filterImage(), the cache is checked for a hit, and early-out is performed. Otherwise, the node is processed, and its result bitmap and location (offset) are cached, but only if it contains two or more children and thus will be visited again during the traversal. Currently, the child count is approximated with the refcount. This is good enough in most cases (and exactly correct for the Chrome use case). We could add an exact child count to the image filter, but this will require violating the immutability of image filters slightly in order to bump the child count as nodes are connected. I leave it up to the reviewer to decide which is better. R=reed@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/230653005 git-svn-id: http://skia.googlecode.com/svn/trunk@14160 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 20:00:42 +0000