History log of /external/skia/include/effects/SkLightingImageFilter.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
958788ab461bf84e8c604a17dba5ebc2d6c27dfa 20-Oct-2016 Mike Reed <reed@google.com> remove 4 legacy flags (clients already updated)

BUG=skia:

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3785

Change-Id: I187e50e09ed7a3316719fae51af770259928fdf9
Reviewed-on: https://skia-review.googlesource.com/3785
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
/external/skia/include/effects/SkLightingImageFilter.h
82b043e87380a64ea4ca736b293ec0ee5c30e676 10-Apr-2016 robertphillips <robertphillips@google.com> Fix roll bot's win gn build

TBR=borenet@google.com,bsalomon@google.com

GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1873063002

Review URL: https://codereview.chromium.org/1873063002
/external/skia/include/effects/SkLightingImageFilter.h
12fa47d33f1e9eb69bb20d9daad2eccfc7288944 09-Apr-2016 robertphillips <robertphillips@google.com> Update LightingImageFilter to sk_sp

TBR=reed@google.com

GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1869763002

Review URL: https://codereview.chromium.org/1869763002
/external/skia/include/effects/SkLightingImageFilter.h
6db0a7bdceb6be85721bfb0db8dea7fd27db5970 02-Apr-2016 senorblanco <senorblanco@chromium.org> Image filters: optimize crop rect application.

If a filter does not affect transparent black, there's no
reason to allow the crop rect to expand beyond the optimal
size determined by onFilterNodeBounds(). So don't enlarge
the bounds unless the filter affects transparent black.

In order to determine which filters affect transparent
black, I've pulled the inverse of the canComputeFastBounds()
logic into a non-recursive, affectsTransparentBlack()
virtual, and left canComputeFastBounds() as a non-virtual,
recursive function that calls it.

BUG=599933
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1848953002
TBR=reed@google.com

Review URL: https://codereview.chromium.org/1848953002
/external/skia/include/effects/SkLightingImageFilter.h
a544eda5ddea215037b1ada6ba5cfc98f6c8ee15 07-Dec-2015 senorblanco <senorblanco@chromium.org> Matrix convolution bounds fix; affectsTransparentBlack fixes.

Because the convolution kernel is (currently) applied in device space,
there's no way to know which object-space pixels will be touched. So
return false from canComputeFastBounds().

The results from the matrixconvolution GM were actually wrong, since
they were showing edge differences on the clip boundaries, where they
should really only show on crop boundaries. I added a crop to the GM
to keep the results the same (which are useful to test the different
convolution tile modes).

While I was at it, SkImageFilter::affectsTransparentBlack() was
inapplicable on most things except color filters, and its use on
leaf nodes was confusing. So I removed it, and made
SkImageFilter::canComputeFastBounds() virtual instead.

BUG=skia:4630

Review URL: https://codereview.chromium.org/1500923004
/external/skia/include/effects/SkLightingImageFilter.h
50c044b9addac613189d6378641c65721e16b2ed 05-Dec-2015 senorblanco <senorblanco@chromium.org> Revert of Matrix convolution bounds fix; affectsTransparentBlack fixes. (patchset #4 id:60001 of https://codereview.chromium.org/1500923004/ )

Reason for revert:
Introduced memory leak; pixel changes in Chrome.

Original issue's description:
> Matrix convolution bounds fix; affectsTransparentBlack fixes.
>
> Because the convolution kernel is (currently) applied in device space,
> there's no way to know which object-space pixels will be touched. So
> return false from canComputeFastBounds().
>
> The results from the matrixconvolution GM were actually wrong, since
> they were showing edge differences on the clip boundaries, where they
> should really only show on crop boundaries. I added a crop to the GM
> to keep the results the same (which are useful to test the different
> convolution tile modes).
>
> While I was at it, SkImageFilter::affectsTransparentBlack() was
> inapplicable on most things except color filters, and its use on
> leaf nodes was confusing. So I removed it, and made
> SkImageFilter::canComputeFastBounds() virtual instead.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/8705ec80518ef551994b82ca5ccaeb0241d6adec

TBR=reed@google.com,reed@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1497083005
/external/skia/include/effects/SkLightingImageFilter.h
8705ec80518ef551994b82ca5ccaeb0241d6adec 04-Dec-2015 senorblanco <senorblanco@chromium.org> Matrix convolution bounds fix; affectsTransparentBlack fixes.

Because the convolution kernel is (currently) applied in device space,
there's no way to know which object-space pixels will be touched. So
return false from canComputeFastBounds().

The results from the matrixconvolution GM were actually wrong, since
they were showing edge differences on the clip boundaries, where they
should really only show on crop boundaries. I added a crop to the GM
to keep the results the same (which are useful to test the different
convolution tile modes).

While I was at it, SkImageFilter::affectsTransparentBlack() was
inapplicable on most things except color filters, and its use on
leaf nodes was confusing. So I removed it, and made
SkImageFilter::canComputeFastBounds() virtual instead.

BUG=skia:

Review URL: https://codereview.chromium.org/1500923004
/external/skia/include/effects/SkLightingImageFilter.h
0abdf766d395ed3b7059511425f431589eca05f6 20-Aug-2015 senorblanco <senorblanco@chromium.org> Reland of Implement canComputeFastBounds() for image filters. (patchset #1 id:1 of https://codereview.chromium.org/1300403003/ )

Reason for revert:
The Mac compile issue was fixed here: https://chromium.googlesource.com/chromium/src/+/fdd331a42ae0b9a6909a121020735161ab61c6e5

Original issue's description:
> Revert of Implement canComputeFastBounds() for image filters. (patchset #8 id:130001 of https://codereview.chromium.org/1296943002/ )
>
> Reason for revert:
> This causes a syntax error.
>
> http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/87819/steps/compile%20%28with%20patch%29/logs/stdio
>
> Original issue's description:
> > Implement canComputeFastBounds() for image filters.
> >
> > Image filters have never implemented this check, which means that
> > filters which affect transparent black falsely claim they can compute
> > their bounds.
> >
> > Implemented an affectsTransparentBlack() virtual for image
> > filters, and a similar helper function for color filters.
> >
> > This will affect the following GMs: imagefiltersscaled
> > (lighting, perlin noise now filter to clip),
> > colorfilterimagefilter (new test case), imagefiltersclipped
> > (perlin noise now filters to clip).
> >
> > Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
> > a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
> > no impact from this change, but will watch the perf bots carefully.
> >
> > BUG=4212
> >
> > Committed: https://skia.googlesource.com/skia/+/915881fe743f9a789037695f543bc6ea189cd0cb
>
> TBR=reed@google.com,senorblanco@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=4212
>
> Committed: https://skia.googlesource.com/skia/+/12d8472d31ea5edb636d7d5214db253570115c40

TBR=reed@google.com,herb@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=4212

Review URL: https://codereview.chromium.org/1301823005
/external/skia/include/effects/SkLightingImageFilter.h
12d8472d31ea5edb636d7d5214db253570115c40 20-Aug-2015 herb <herb@google.com> Revert of Implement canComputeFastBounds() for image filters. (patchset #8 id:130001 of https://codereview.chromium.org/1296943002/ )

Reason for revert:
This causes a syntax error.

http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/87819/steps/compile%20%28with%20patch%29/logs/stdio

Original issue's description:
> Implement canComputeFastBounds() for image filters.
>
> Image filters have never implemented this check, which means that
> filters which affect transparent black falsely claim they can compute
> their bounds.
>
> Implemented an affectsTransparentBlack() virtual for image
> filters, and a similar helper function for color filters.
>
> This will affect the following GMs: imagefiltersscaled
> (lighting, perlin noise now filter to clip),
> colorfilterimagefilter (new test case), imagefiltersclipped
> (perlin noise now filters to clip).
>
> Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
> a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
> no impact from this change, but will watch the perf bots carefully.
>
> BUG=4212
>
> Committed: https://skia.googlesource.com/skia/+/915881fe743f9a789037695f543bc6ea189cd0cb

TBR=reed@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=4212

Review URL: https://codereview.chromium.org/1300403003
/external/skia/include/effects/SkLightingImageFilter.h
915881fe743f9a789037695f543bc6ea189cd0cb 20-Aug-2015 senorblanco <senorblanco@chromium.org> Implement canComputeFastBounds() for image filters.

Image filters have never implemented this check, which means that
filters which affect transparent black falsely claim they can compute
their bounds.

Implemented an affectsTransparentBlack() virtual for image
filters, and a similar helper function for color filters.

This will affect the following GMs: imagefiltersscaled
(lighting, perlin noise now filter to clip),
colorfilterimagefilter (new test case), imagefiltersclipped
(perlin noise now filters to clip).

Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
no impact from this change, but will watch the perf bots carefully.

BUG=4212

Review URL: https://codereview.chromium.org/1296943002
/external/skia/include/effects/SkLightingImageFilter.h
2f0dbc761a626473c19db7de561c7072b12953c5 20-Aug-2015 robertphillips <robertphillips@google.com> Update SkLightingShader to support rotation

This also:
makes the SkLightingShader handle normal maps where the rects aren't aligned between the diffuse and normal maps.

adds a light aggregating class (Lights) to SkLightingShader (along with a Builder nested class).

Split out of https://codereview.chromium.org/1261433009/ (Add SkCanvas::drawLitAtlas call)

Committed: https://skia.googlesource.com/skia/+/45b59ed6e4e231814dbdb9f707b3d2a7ee50de84

Review URL: https://codereview.chromium.org/1291783003
/external/skia/include/effects/SkLightingImageFilter.h
d0cf9d831f7f4c98d48f52e6850db4ade1dd9422 06-Aug-2015 robertphillips <robertphillips@google.com> Remove SK_LEGACY_SKPOINT3_CTORS flag

Cannot land before Blink https://codereview.chromium.org/1274673002/ (Remove reliance on legacy Skia SkPoint3 ctors in FELighting.cpp)

Review URL: https://codereview.chromium.org/1269383003
/external/skia/include/effects/SkLightingImageFilter.h
3d32d768cd8b66c49c070495c08f7933b9dd2423 13-Jul-2015 robertphillips <robertphillips@google.com> Add new SkPoint3 class

The existing Light filter and the upcoming Lighting Shader both need a Point3 class

Review URL: https://codereview.chromium.org/1229693009
/external/skia/include/effects/SkLightingImageFilter.h
36352bf5e38f45a70ee4f4fc132a38048d38206d 26-Mar-2015 mtklein <mtklein@chromium.org> C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}

NOPRESUBMIT=true

BUG=skia:
DOCS_PREVIEW= https://skia.org/?cl=1037793002

Review URL: https://codereview.chromium.org/1037793002
/external/skia/include/effects/SkLightingImageFilter.h
24e06d5244ae96e440410e1d76e039983b2efac9 18-Mar-2015 senorblanco <senorblanco@chromium.org> Remove uniqueID from all filter serialization.

(This is essentially a revert of https://codereview.chromium.org/503833002/.)

This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs.

Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.)

BUG=skia:

Review URL: https://codereview.chromium.org/1019493002
/external/skia/include/effects/SkLightingImageFilter.h
72c9faab45124e08c85f70ca38536914862d947c 09-Jan-2015 mtklein <mtklein@chromium.org> Fix up all the easy virtual ... SK_OVERRIDE cases.

This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.

for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end

BUG=skia:

Review URL: https://codereview.chromium.org/806653007
/external/skia/include/effects/SkLightingImageFilter.h
3f3b3d003527861dc0bd89733857576408906431 01-Dec-2014 mtklein <mtklein@chromium.org> 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

Review URL: https://codereview.chromium.org/769953002
/external/skia/include/effects/SkLightingImageFilter.h
6e78293ee896020104ffc4c23b565073e9a49893 01-Dec-2014 mtklein <mtklein@google.com> Revert of Remove SK_SUPPORT_LEGACY_DEEPFLATTENING. (patchset #1 id:1 of 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
/external/skia/include/effects/SkLightingImageFilter.h
52c293547b973f7fb5de3c83f5062b07d759ab88 01-Dec-2014 mtklein <mtklein@chromium.org> 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:

Review URL: https://codereview.chromium.org/769953002
/external/skia/include/effects/SkLightingImageFilter.h
5e5f948b6b363dbfc8c076d8ff0c6b8e9ea99958 26-Aug-2014 senorblanco <senorblanco@chromium.org> Reimplement deserialization of SkImageFilter's uniqueID.

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
/external/skia/include/effects/SkLightingImageFilter.h
9fa60daad4d5f54c0dbe3dbcc7608a8f6d721187 21-Aug-2014 reed <reed@google.com> Simplify flattening to just write enough to call the 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
/external/skia/include/effects/SkLightingImageFilter.h
9ea3d57fde28a5fe4487a111dc3dd49418235e5e 08-Jul-2014 senorblanco <senorblanco@chromium.org> Clean up SkImageFilter constructors.

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
/external/skia/include/effects/SkLightingImageFilter.h
8b0e8ac5f582de80356019406e2975079bf0829d 30-Jan-2014 commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Refactor read and write buffers.

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
/external/skia/include/effects/SkLightingImageFilter.h
1a5e51f94ed8cb01600184119e52bb64bdb3dccc 27-Jan-2014 reed@google.com <reed@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81> remove SkScalarMul from public headers

BUG=skia:

Review URL: https://codereview.chromium.org/132453008

git-svn-id: http://skia.googlecode.com/svn/trunk@13189 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
b295fb6ff3222453912dfcb7a1ea5184d40014b5 10-Oct-2013 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Change SkImageFilter's cropRect from SkIRect to a CropRect struct, containing an SkRect and flags indicating which parameters are set.

NOTE: this will require SK_CROP_RECT_IS_INT=1 to be set in Chrome until Blink has been updated to use SkImageFilter::CropRect. Include https://codereview.chromium.org/26528002/ with the Skia roll.

Note also that SK_CROP_RECT_IS_INT is a temporary measure until all call sites in Blink have been updated to use SkRect.

R=reed@google.com

Review URL: https://codereview.chromium.org/26371002

git-svn-id: http://skia.googlecode.com/svn/trunk@11692 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
4b681bc95b14e081f1cc5b68cb755d57fc8eb977 13-Sep-2013 commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Fixed issues found by fuzzer

Last week, the fuzzer found a few numerical issue with filters and I had written some fixes for them. Here are the fixes with some unit tests.

For senorblanco : So I figured out what was asserting when we'd get a 0 width "result" in SkBicubicImageFilter::onFilterImage(). Basically, if the "result" SkBitmap object calls SkBitmap::setConfig() with "width" and/or "height" set to 0, then the SkBitmap object will call SkBitmap::reset(), making the SkBitmap object's config invalid. At this point, calling SkBitmap::getAddr32() will assert, even without attempting to dereference the data pointer, because the SkBitmap's config is invalid. If height is valid, but width is 0, then this call to SkBitmap::getAddr32() happens directly in SkBicubicImageFilter::onFilterImage() a few lines lower and asserts right away.

BUG=
R=senorblanco@google.com, senorblanco@chromium.org, bsalomon@google.com

Author: sugoi@chromium.org

Review URL: https://chromiumcodereview.appspot.com/23533042

git-svn-id: http://skia.googlecode.com/svn/trunk@11249 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
4e16bb2a322f2bd16cb1afd2f78c27e420a4b9db 26-Jul-2013 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Implement crop rect for lighting image filters. Changes for the CPU path were fairly straightforward: use the bounds rectangle when traversing the pixels, not the source rectangle.

For the GPU path, this required modifying the signature of SkImageFilter::asNewEffect() to receive the bounds offset, so that the lighting filters could offset the light position by the offset. It also required modifying the base-class implementation of SkImageFilter::filterImageGPU() (which implements single-pass filters) to intersect against the bounds rect, to pass its offset to asNewEffect(), and to modify the caller's offset (so it's drawn in the correct place).

Note: this will require rebaselining the lighting GM. Six new test cases were added, to accommodate a cropped version of each lighting filter.

R=bsalomon@google.com, reed@google.com

Review URL: https://codereview.chromium.org/20426002

git-svn-id: http://skia.googlecode.com/svn/trunk@10379 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
377c14a1e648f4427bd11474fad8ac264d98aff2 04-Feb-2013 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Nuke SkSingleInputImageFilter. 99% of its functionality was refactored into SkImageFilterUtils in https://code.google.com/p/skia/source/detail?r=7467, so it has outlived its usefulness.

Review URL: https://codereview.appspot.com/7277055

git-svn-id: http://skia.googlecode.com/svn/trunk@7563 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
e16efc1882ab34a0bb3ae361a2d37f840044cf87 26-Jan-2013 skia.committer@gmail.com <skia.committer@gmail.com@2bbb7eff-a529-9590-31e7-b0007b416f81> Sanitizing source files in Skia_Periodic_House_Keeping

git-svn-id: http://skia.googlecode.com/svn/trunk@7406 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
254eae2b04a7f810de0ed92803a8bdd18d11babf 05-Oct-2012 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Change SkLightingImageFilter to derive from SkSingleInputImageFilter, so that it can participate in filter DAGs.

No tests yet.

Review URL: https://codereview.appspot.com/6620055

git-svn-id: http://skia.googlecode.com/svn/trunk@5832 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
894790d77c56cd4bae8070331d275c6d2897e33c 11-Jul-2012 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> This patch implements the diffuse and specular lighting filters in Ganesh.
There are three light types for each: distant, point and spot, whose code
generation lives in a GrGLLight class hierarchy. This similar to the CPU
implementation, where each light type provides a function to compute the vector
from the surface plane to the light (surfaceToLight) and to compute the light
colour (emitLightColour). Instead of templated member functions, as in the CPU
implementation, these are virtual functions to emit the light-specific GLSL
code.

All of the code for the GPU path lives in the same file as that for the CPU
path, SkLightingImageFilter.cpp. In order to provide Ganesh a hook to access
it, SkImageFilter now has a asNewCustomStage() virtual, which allows an image
filter to return a GrCustomStage representing that filter.

Note that this patch does not handle the border conditions correctly (the
[top|bottom][Left|Right]Normal() functions in the CPU implementation). That
will come in a future patch.

Review URL: http://codereview.appspot.com/6345081/



git-svn-id: http://skia.googlecode.com/svn/trunk@4535 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
bdb1ec453a36b3e8e8800713aef0dce934e6a6a7 09-Jul-2012 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Minor cleanup in lighting image filters: Made the light color a member of the
light, rather than the filter, so computation is localized. Changed a couple
of non-const refs in the image filter creation API const refs. Changed "const
SkColor&" to "SkColor", since it's just a uint32_t anyway.

Review URL: http://codereview.appspot.com/6352071/


git-svn-id: http://skia.googlecode.com/svn/trunk@4466 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
0833777df1f05adafd9b70c666a72d80defa4f6b 26-Jun-2012 djsollen@google.com <djsollen@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81> Cleanup flattening code to properly serialize lighting image filters.
Review URL: https://codereview.appspot.com/6333070

git-svn-id: http://skia.googlecode.com/svn/trunk@4340 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h
f49b429ceface4f75f5f96570ea5a8b94896529d 22-Jun-2012 senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> Raster implementation of diffuse and specular lighting filters. Externally,
the caller instantiates a light (distant, point or spot), and an
SkDiffuseLightingFilter or SkSpecularLightingImageFilter with that light. A
Sobel edge detection filter is applied to the alpha of the incoming bitmap, and
the result is used as a height map for lighting calculations.

Review URL: http://codereview.appspot.com/6302101/



git-svn-id: http://skia.googlecode.com/svn/trunk@4314 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/include/effects/SkLightingImageFilter.h