aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/effects/SkMorphologyImageFilter.cpp
Commit message (Collapse)AuthorAge
* Push isEqual/onIsEqual down from GrProcessor to subclasses.Gravatar bsalomon2014-10-15
| | | | | | R=joshualitt@google.com Review URL: https://codereview.chromium.org/654273002
* Remove uses of GrAutoScratchTexture.Gravatar bsalomon2014-10-14
| | | | | | | | | | Rename GrContext::lockAndRefScratchTexture to refScratchTexture. GrSurface::writePixels returns bool instead of void. BUG=skia:2889 Review URL: https://codereview.chromium.org/638403003
* Create helper functions to use in computeInvariantOutput callsGravatar egdaniel2014-10-13
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/643743003
* FPs now use the correct builder types(just a rename)Gravatar joshualitt2014-10-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/648463003
* Remove tab parameter from GrGLSLMulVarBy4f functionGravatar egdaniel2014-10-09
| | | | | | | | | With pretty printing of shader code, there is no longer a need to explictily have tabs in our code. BUG=skia: Review URL: https://codereview.chromium.org/648463002
* Add isSingleComponent bool to getConstantColorComponentGravatar egdaniel2014-10-03
| | | | | | | | | | Initial step to allowing effects to use/output 1 or 4 color/coverage components. This cl doesn't change any current logic and all effects still assume they are working with 4 components. BUG=skia: Committed: https://skia.googlesource.com/skia/+/3b8af078281a5a20f951b9fd84f38d92b8f6217b Review URL: https://codereview.chromium.org/608253002
* Revert of Add isSingleComponent bool to getConstantColorComponent (patchset ↵Gravatar robertphillips2014-10-02
| | | | | | | | | | | | | | | | | | | | | | | #6 id:100001 of https://codereview.chromium.org/608253002/) Reason for revert: Changing some GMs Original issue's description: > Add isSingleComponent bool to getConstantColorComponent > > Initial step to allowing effects to use/output 1 or 4 color/coverage components. This cl doesn't change any current logic and all effects still assume they are working with 4 components. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/3b8af078281a5a20f951b9fd84f38d92b8f6217b TBR=joshualitt@chromium.org,bsalomon@google.com,reed@google.com,egdaniel@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/617853003
* Add isSingleComponent bool to getConstantColorComponentGravatar egdaniel2014-10-02
| | | | | | | | Initial step to allowing effects to use/output 1 or 4 color/coverage components. This cl doesn't change any current logic and all effects still assume they are working with 4 components. BUG=skia: Review URL: https://codereview.chromium.org/608253002
* Patch to create a distinct geometry processor. The vast majority of this patchGravatar joshualitt2014-09-23
| | | | | | | | | | | | | is just a rename. The meat is in GrGeometryProcessor, GrProcessor, GrGL*Processor, GrProcessorStage, Gr*BackendProcessorFactory, GrProcessUnitTestFactory, and the builders BUG=skia: R=bsalomon@google.com Author: joshualitt@chromium.org Review URL: https://codereview.chromium.org/582963002
* removing GrDrawEffectGravatar joshualitt2014-09-16
| | | | | | | | | | | | BUG=skia: Committed: https://skia.googlesource.com/skia/+/8ddbe8b9366c8c59c4fb55f01f253de8a0b37d6e R=bsalomon@google.com Author: joshualitt@chromium.org Review URL: https://codereview.chromium.org/571163002
* Revert of removing GrDrawEffect (patchset #4 id:60001 of ↵Gravatar joshualitt2014-09-16
| | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/571163002/) Reason for revert: reverting to unblock another revert Original issue's description: > removing GrDrawEffect > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/8ddbe8b9366c8c59c4fb55f01f253de8a0b37d6e R=bsalomon@google.com TBR=bsalomon@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Author: joshualitt@chromium.org Review URL: https://codereview.chromium.org/577593003
* removing GrDrawEffectGravatar joshualitt2014-09-16
| | | | | | | | | BUG=skia: R=bsalomon@google.com Author: joshualitt@chromium.org Review URL: https://codereview.chromium.org/571163002
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* make allocPixels throw on failureGravatar reed2014-09-02
| | | | | | | | | BUG=skia: R=mtklein@google.com, fmalita@google.com, fmalita@chromium.org Author: reed@google.com Review URL: https://codereview.chromium.org/510423005
* Reimplement deserialization of SkImageFilter's uniqueID.Gravatar senorblanco2014-08-26
| | | | | | | | | | | | | | | | | | | | | | | 9fa60d ("Simplify flattening to just write enough ... ") simplified just a tad too much. In particular, it disabled deserialization of SkImageFilter's uniqueID, which in turn caused the failure of SkImageFilter's cache, which caused a large regression in Chrome's SVG filter performance. The medium-term fix is to switch to the new SkRecordDraw SkPicture backend, which will make the unique IDs unnecessary. This change is an "in case of emergecy" CL, in the event that there are problems switching on the new backend in Chrome. For that reason, it's minimalist: only the filters used by Chrome are modified, and whitespace changes are kept to a minimum. In this way, it should be easy to revert once the new backend goes in. R=reed@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/503833002
* 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
* Initial refactor of shaderbuilder to prepare for geometry shadersGravatar joshualitt2014-08-21
| | | | | | | | | | | gitignore for eclipse BUG=skia: R=bsalomon@google.com, bsalomon@chromium.org Author: joshualitt@chromium.org Review URL: https://codereview.chromium.org/491673002
* 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
* Check all scratch texture allocations for image filters.Gravatar senorblanco2014-08-15
| | | | | | | | | | BUG=403677 R=bsalomon@google.com NOTREECHECKS=true Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/473283002
* Rename GrGLUniformManager to GrGLProgramDataManagerGravatar kkinnunen2014-07-30
| | | | | | | | | | | | | Rename GrGLUniformManager to GrGLProgramDataManager in anticipation that the class would be used to manage shader resources that are not uniforms. This is needed in order to implement NVPR on GLES. R=bsalomon@google.com Author: kkinnunen@nvidia.com Review URL: https://codereview.chromium.org/365853002
* Allow GrGLEffects to produce variable length keys.Gravatar bsalomon2014-07-21
| | | | | | | | R=robertphillips@google.com, jvanverth@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/385713005
* This moves us towards variable length effect keys. The overall program key ↵Gravatar bsalomon2014-07-11
| | | | | | | | | | now allows for it. After the header it stores an array of offsets to effect keys. This allows us to grab the effect keys to pass to effects when they generate code. It also ensures that we can't get a collision by sets of keys that are different lengths but are the same when appended together. R=robertphillips@google.com, jvanverth@google.com, egdaniel@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/356513003
* Goodbye GrEffectRef.Gravatar bsalomon2014-07-08
| | | | | | | | | | Also, reworked some var names and comments around SkShader::asNewEffect. R=robertphillips@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/374923002
* 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 GrEffect::CreateEffectRef and GrEffect::AutoEffectRef.Gravatar bsalomon2014-07-08
| | | | | | | | R=robertphillips@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/371103003
* use colortype instead of configGravatar reed2014-06-02
| | | | | | | | | | | | clone of https://codereview.chromium.org/305133006/ TBR= BUG=skia: Author: reed@google.com Review URL: https://codereview.chromium.org/301233011
* Convert GrCrash->SkFAIL GrDebugCrash->SkDEBUGFAILGravatar commit-bot@chromium.org2014-04-30
| | | | | | | | | | R=robertphillips@google.com, reed@google.com, mtklein@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/257393004 git-svn-id: http://skia.googlecode.com/svn/trunk@14460 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert of Revert of Rename kPMColor_SkColorType to kN32_SkColorType. ↵Gravatar commit-bot@chromium.org2014-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/234243002/) Reason for revert: Want to reland the original CL. Original issue's description: > Revert of Rename kPMColor_SkColorType to kN32_SkColorType. (https://codereview.chromium.org/227433009/) > > Reason for revert: > breaking the Chrome deps roll. > http://build.chromium.org/p/chromium.linux/builders/Linux%20GN%20%28dbg%29/builds/839/steps/compile/logs/stdio > > Original issue's description: > > Rename kPMColor_SkColorType to kN32_SkColorType. > > > > The new name better represents what this flag means. > > > > BUG=skia:2384 > > > > Committed: http://code.google.com/p/skia/source/detail?r=14117 > > TBR=reed@google.com,scroggo@google.com > NOTREECHECKS=true > NOTRY=true > BUG=skia:2384 > > Committed: http://code.google.com/p/skia/source/detail?r=14144 R=reed@google.com, bensong@google.com TBR=bensong@google.com, reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2384 Author: scroggo@google.com Review URL: https://codereview.chromium.org/235523003 git-svn-id: http://skia.googlecode.com/svn/trunk@14156 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert of Rename kPMColor_SkColorType to kN32_SkColorType. ↵Gravatar commit-bot@chromium.org2014-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/227433009/) Reason for revert: Chrome's side of define changes not easy to figure out quickly. Reverting this for DEPS roll for now. Original issue's description: > Rename kPMColor_SkColorType to kN32_SkColorType. > > The new name better represents what this flag means. > > BUG=skia:2384 > > Committed: http://code.google.com/p/skia/source/detail?r=14117 R=reed@google.com, scroggo@google.com TBR=reed@google.com, scroggo@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2384 Author: bensong@google.com Review URL: https://codereview.chromium.org/234833003 git-svn-id: http://skia.googlecode.com/svn/trunk@14149 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert of Revert of Rename kPMColor_SkColorType to kN32_SkColorType. ↵Gravatar commit-bot@chromium.org2014-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/234243002/) Reason for revert: fixes on the chrome side are landing (brettw), keep fingers crossed. Original issue's description: > Revert of Rename kPMColor_SkColorType to kN32_SkColorType. (https://codereview.chromium.org/227433009/) > > Reason for revert: > breaking the Chrome deps roll. > http://build.chromium.org/p/chromium.linux/builders/Linux%20GN%20%28dbg%29/builds/839/steps/compile/logs/stdio > > Original issue's description: > > Rename kPMColor_SkColorType to kN32_SkColorType. > > > > The new name better represents what this flag means. > > > > BUG=skia:2384 > > > > Committed: http://code.google.com/p/skia/source/detail?r=14117 > > TBR=reed@google.com,scroggo@google.com > NOTREECHECKS=true > NOTRY=true > BUG=skia:2384 > > Committed: http://code.google.com/p/skia/source/detail?r=14144 R=reed@google.com, scroggo@google.com TBR=reed@google.com, scroggo@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2384 Author: bensong@google.com Review URL: https://codereview.chromium.org/233813004 git-svn-id: http://skia.googlecode.com/svn/trunk@14145 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert of Rename kPMColor_SkColorType to kN32_SkColorType. ↵Gravatar commit-bot@chromium.org2014-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/227433009/) Reason for revert: breaking the Chrome deps roll. http://build.chromium.org/p/chromium.linux/builders/Linux%20GN%20%28dbg%29/builds/839/steps/compile/logs/stdio Original issue's description: > Rename kPMColor_SkColorType to kN32_SkColorType. > > The new name better represents what this flag means. > > BUG=skia:2384 > > Committed: http://code.google.com/p/skia/source/detail?r=14117 R=reed@google.com, scroggo@google.com TBR=reed@google.com, scroggo@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2384 Author: bensong@google.com Review URL: https://codereview.chromium.org/234243002 git-svn-id: http://skia.googlecode.com/svn/trunk@14144 2bbb7eff-a529-9590-31e7-b0007b416f81
* Rename kPMColor_SkColorType to kN32_SkColorType.Gravatar commit-bot@chromium.org2014-04-09
| | | | | | | | | | | | | The new name better represents what this flag means. BUG=skia:2384 R=reed@google.com Author: scroggo@google.com Review URL: https://codereview.chromium.org/227433009 git-svn-id: http://skia.googlecode.com/svn/trunk@14117 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement support for expanding crop rects in image filtersGravatar senorblanco@chromium.org2014-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NOTE: this patch set is based on https://codereview.chromium.org/189913021/, and needs that patch to land first. Until now, crop rects in Skia have only been able to reduce the size of the destination bounds, but not expand them. SVG semantics require the latter as well. The heart of the change is in applyCropRect(), which now assigns each edge, instead of doing an intersection with the crop rect. In order to support this (and still work well with tiled drawing) we need to clip the resulting crop rect to the clipping region of the filters. This uses the Context struct previously landed from https://codereview.chromium.org/189913021/. Many of the pixel loops are not yet ready to handle a destination rect larger than the source rect. So we provide a convenience version of applyCropRect() which creates an offscreen and pads it out with transparent black. Once the pixel loops and shaders have been fixed to support larger destination bounds, they should be switched back to the non-drawing version of applyCropRect(). BUG=skia: R=bsalomon@google.com, reed@google.com Committed: https://code.google.com/p/skia/source/detail?r=13805 Review URL: https://codereview.chromium.org/198003008 git-svn-id: http://skia.googlecode.com/svn/trunk@13809 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert "Implement support for expanding crop rects in image filters"Gravatar senorblanco@chromium.org2014-03-14
| | | | | | | | | | | Breaking ImageFilterTests unit test. TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/196353021 git-svn-id: http://skia.googlecode.com/svn/trunk@13806 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement support for expanding crop rects in image filtersGravatar senorblanco@chromium.org2014-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NOTE: this patch set is based on https://codereview.chromium.org/189913021/, and needs that patch to land first. Until now, crop rects in Skia have only been able to reduce the size of the destination bounds, but not expand them. SVG semantics require the latter as well. The heart of the change is in applyCropRect(), which now assigns each edge, instead of doing an intersection with the crop rect. In order to support this (and still work well with tiled drawing) we need to clip the resulting crop rect to the clipping region of the filters. This uses the Context struct previously landed from https://codereview.chromium.org/189913021/. Many of the pixel loops are not yet ready to handle a destination rect larger than the source rect. So we provide a convenience version of applyCropRect() which creates an offscreen and pads it out with transparent black. Once the pixel loops and shaders have been fixed to support larger destination bounds, they should be switched back to the non-drawing version of applyCropRect(). BUG=skia: R=bsalomon@google.com, reed@google.com Review URL: https://codereview.chromium.org/198003008 git-svn-id: http://skia.googlecode.com/svn/trunk@13805 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement support for a Context parameter in image filtersGravatar senorblanco@chromium.org2014-03-14
| | | | | | | | | | | | | | | Some upcoming work (support for expanding crop rects) requires the clip bounds to be available during filter traversal. This change replaces the SkMatrix parameter in the onFilterImage() traversals with a Context parameter. It contains the CTM, as well as the clip bounds. BUG=skia: R=reed@google.com Review URL: https://codereview.chromium.org/189913021 git-svn-id: http://skia.googlecode.com/svn/trunk@13803 2bbb7eff-a529-9590-31e7-b0007b416f81
* Cleanup patch to move all of SkImageFilterUtils into SkImageFilter.Gravatar senorblanco@chromium.org2014-03-03
| | | | | | | | | | | | | | This was a utility class that dates from before GPU code was allowed in core. Now that it is, there's no reason not to have this functionality in SkImageFilter. Covered by existing tests. R=reed@google.com Review URL: https://codereview.chromium.org/185973003 git-svn-id: http://skia.googlecode.com/svn/trunk@13646 2bbb7eff-a529-9590-31e7-b0007b416f81
* use SkColorType instead of SkBitmap::Config in views/effectsGravatar commit-bot@chromium.org2014-02-16
| | | | | | | | | | | R=scroggo@google.com, reed@google.com TBR=scroggo Author: reed@chromium.org Review URL: https://codereview.chromium.org/168843002 git-svn-id: http://skia.googlecode.com/svn/trunk@13469 2bbb7eff-a529-9590-31e7-b0007b416f81
* Make SkImageFilter methods const.Gravatar commit-bot@chromium.org2014-02-05
| | | | | | | | | | | | | | SkImageFilter had some non-const methods that could all be made const. This is a first step towards making SkImageFilter immutable. BUG=skia:2097 R=mtklein@google.com, reed@google.com, robertphillips@google.com Author: dominikg@chromium.org Review URL: https://codereview.chromium.org/148883011 git-svn-id: http://skia.googlecode.com/svn/trunk@13330 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement correct clipping for image filters.Gravatar senorblanco@chromium.org2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | Image filters in Skia currently clip the size of the the offscreen bitmap used for filtering to the device clip bounds. This means that any pixel-moving filter (e.g., blur) has edge artifacts at the clip boundaries. This is problematic for tiling, where a single SkPicture is played back with a clip set to the tile boundaries. By implementing the onFilterBounds() traversal, and using it in saveLayer() when a filter is present, we can clip the layer to the expanded clip rect. Note that this requires that the traversal be performed in reverse as compared to computeFastBounds(). (It's also done in device space, unlike computeFastBounds()). New test imagefiltersclipped tests pixel-moving filters when clipped by various clip rects. New test imageblurtiled tests tiled (compositor-style) rendering of blurred text. There should be no artifacts at the tile boundaries. BUG=337831 R=reed@google.com Review URL: https://codereview.chromium.org/23011012 git-svn-id: http://skia.googlecode.com/svn/trunk@13323 2bbb7eff-a529-9590-31e7-b0007b416f81
* Refactor read and write buffers.Gravatar commit-bot@chromium.org2014-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Eliminates SkFlattenable{Read,Write}Buffer, promoting SkOrdered{Read,Write}Buffer a step each in the hierarchy. What used to be this: SkFlattenableWriteBuffer -> SkOrderedWriteBuffer SkFlattenableReadBuffer -> SkOrderedReadBuffer SkFlattenableReadBuffer -> SkValidatingReadBuffer is now SkWriteBuffer SkReadBuffer -> SkValidatingReadBuffer Benefits: - code is simpler, names are less wordy - the generic SkFlattenableFooBuffer code in SkPaint was incorrect; removed - write buffers are completely devirtualized, important for record speed This refactoring was mostly mechanical. You aren't going to find anything interesting in files with less than 10 lines changed. BUG=skia: R=reed@google.com, scroggo@google.com, djsollen@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/134163010 git-svn-id: http://skia.googlecode.com/svn/trunk@13245 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement a computeFastBounds() traversal for SkImageFilter.Gravatar senorblanco@chromium.org2014-01-27
| | | | | | | | | | | This allows for correct culling of primitives which have image filters applied. R=reed@google.com BUG=skia: Review URL: https://codereview.chromium.org/137423005 git-svn-id: http://skia.googlecode.com/svn/trunk@13207 2bbb7eff-a529-9590-31e7-b0007b416f81
* [Reland of r13154, since the Housekeeping bot seems to have reverted it in ↵Gravatar senorblanco@chromium.org2014-01-24
| | | | | | | | | | | | | | | | | | r13155. Next time I'll put the "do not disturb" sign on my commit.] Refactor SkMorphologyImageFilter, CPU and GPU paths. This required making opts/ dependent on effects/, so that we could use the SkMorphologyProc type in SkMorphologyImageFilter.h. Correctness and performance covered by existing tests; no change in functionality. R=bsalomon@google.com, djsollen@google.com, reed@google.com Committed: https://code.google.com/p/skia/source/detail?r=13154 BUG=skia: Review URL: https://codereview.chromium.org/135013004 git-svn-id: http://skia.googlecode.com/svn/trunk@13168 2bbb7eff-a529-9590-31e7-b0007b416f81
* Sanitizing source files in Housekeeper-NightlyGravatar skia.committer@gmail.com2014-01-23
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@13155 2bbb7eff-a529-9590-31e7-b0007b416f81
* Refactor SkMorphologyImageFilter, CPU and GPU paths. This required making ↵Gravatar senorblanco@chromium.org2014-01-23
| | | | | | | | | | | | opts/ dependent on effects/, so that we could use the SkMorphologyProc type in SkMorphologyImageFilter.h. Correctness and performance covered by existing tests; no change in functionality. R=bsalomon@google.com, djsollen@google.com, reed@google.com Review URL: https://codereview.chromium.org/135013004 git-svn-id: http://skia.googlecode.com/svn/trunk@13154 2bbb7eff-a529-9590-31e7-b0007b416f81
* Apply the CTM to filter parameters for SkBlurImageFilter, ↵Gravatar senorblanco@chromium.org2014-01-20
| | | | | | | | | | | | SkDropShadowImageFilter, SkDisplacementMapEffect and SkMorphologyImageFilter. I had resisted this (and may later put in an assert that the CTM contains no rotation, skew or perspective), but it just makes the filters play better with Skia generally. This revealed that the displacement map was not handling clipping or upstream cropping at all well (the color would "swim" through the displacement at the edge of the clip rect). Fixed by passing through the correct offsets to the bitmap accesses in both raster and GPU paths. Same for morphology. R=sugoi@google.com Review URL: https://codereview.chromium.org/137053003 git-svn-id: http://skia.googlecode.com/svn/trunk@13127 2bbb7eff-a529-9590-31e7-b0007b416f81
* Make SkImageFilter crop rects relative to the primitive origin, instead of ↵Gravatar senorblanco@chromium.org2014-01-03
| | | | | | | | | | | | | | | | | | relative to their parent's crop rect. This is required by SVG semantics, and is more sane anyway. To do this, this patch changes the "offset/loc" parameter in filterImage() / onFilterImage() from an inout-param to an out-param only, so that the calling filter can know how much the input filter wants its result offset (and doesn't include the original primitive position). This offset can then be applied to the current filter's crop rect. (I've renamed the parameter "offset" in all cases to make this clear.) This makes the call sites in SkCanvas/SkGpuDevice responsible for applying the resulting offset to the primitive's position, which is actually a fairly small change. This change also fixes SkTileImageFilter and SkOffsetImageFilter to correctly handle an input offset, which they weren't before. This required modifying the GM's, since they assumed the broken behaviour. NOTE: this will require rebaselining the imagefiltersgraph test, since it has a new test case. NOTE: this will "break" the Blink layout tests css3/filters/effect-reference-subregion-chained-hw.html and css3/filters/effect-reference-subregion-hw.html, but it actually makes them give correct results. It should be suppressed on the skia roll, and I'll rebaseline it. R=reed@google.com Review URL: https://codereview.chromium.org/112803004 git-svn-id: http://skia.googlecode.com/svn/trunk@12895 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fixed bad bitmap size crashesGravatar commit-bot@chromium.org2013-12-04
| | | | | | | | | | | | | | | There were 2 issues : 1 ) If the size of an SkBitmap's underlying SkPixelRef's alocated memory is too small to fit the bitmap, then the deserialization will now check this and set an error appropriately. 2 ) If a device fails to allocate its pixels, the device will be deleted and NULL will be returned to avoid attempting to draw on a bad device. BUG= R=senorblanco@chromium.org, reed@google.com, sugoi@google.com, halcanary@google.com, mtklein@google.com Author: sugoi@chromium.org Review URL: https://codereview.chromium.org/92793002 git-svn-id: http://skia.googlecode.com/svn/trunk@12484 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 04:37:02 +0000