aboutsummaryrefslogtreecommitdiffhomepage
path: root/include/effects/SkLightingImageFilter.h
Commit message (Collapse)AuthorAge
* C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}Gravatar mtklein2015-03-25
| | | | | | | | | NOPRESUBMIT=true BUG=skia: DOCS_PREVIEW= https://skia.org/?cl=1037793002 Review URL: https://codereview.chromium.org/1037793002
* Remove uniqueID from all filter serialization.Gravatar senorblanco2015-03-18
| | | | | | | | | | | | (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
* Fix up all the easy virtual ... SK_OVERRIDE cases.Gravatar mtklein2015-01-09
| | | | | | | | | | | | 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
* 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
* 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
* 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
* 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
* 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
* remove SkScalarMul from public headersGravatar reed@google.com2014-01-27
| | | | | | | | BUG=skia: Review URL: https://codereview.chromium.org/132453008 git-svn-id: http://skia.googlecode.com/svn/trunk@13189 2bbb7eff-a529-9590-31e7-b0007b416f81
* Change SkImageFilter's cropRect from SkIRect to a CropRect struct, ↵Gravatar senorblanco@chromium.org2013-10-10
| | | | | | | | | | | | | | 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
* Fixed issues found by fuzzerGravatar commit-bot@chromium.org2013-09-13
| | | | | | | | | | | | | | | 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
* Implement crop rect for lighting image filters. Changes for the CPU path ↵Gravatar senorblanco@chromium.org2013-07-26
| | | | | | | | | | | | | | 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
* Nuke SkSingleInputImageFilter. 99% of its functionality was refactored into ↵Gravatar senorblanco@chromium.org2013-02-04
| | | | | | | | 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
* Sanitizing source files in Skia_Periodic_House_KeepingGravatar skia.committer@gmail.com2013-01-26
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@7406 2bbb7eff-a529-9590-31e7-b0007b416f81
* Change SkLightingImageFilter to derive from SkSingleInputImageFilter, so ↵Gravatar senorblanco@chromium.org2012-10-05
| | | | | | | | | | 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
* This patch implements the diffuse and specular lighting filters in Ganesh. Gravatar senorblanco@chromium.org2012-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Minor cleanup in lighting image filters: Made the light color a member of theGravatar senorblanco@chromium.org2012-07-09
| | | | | | | | | | | 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
* Cleanup flattening code to properly serialize lighting image filters.Gravatar djsollen@google.com2012-06-26
| | | | | | Review URL: https://codereview.appspot.com/6333070 git-svn-id: http://skia.googlecode.com/svn/trunk@4340 2bbb7eff-a529-9590-31e7-b0007b416f81
* Raster implementation of diffuse and specular lighting filters. Externally,Gravatar senorblanco@chromium.org2012-06-22
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 00:25:16 +0000