There were 4 classes in blink that derived from SkImageFilter :
- TileImageFilter -> SkTileImageFilter
- OffsetImageFilter -> SkOffsetImageFilter (already existed)
- FloodImageFilter -> SkFloodImageFilter
- CompositeImageFilter -> SkCompositeImageFilter
All functions were copied as is, without modification (except for warnings fixes), except for the offset filter, which was merged into the existing SkOffsetImageFilter class, as a special case when a crop rect is provided. Since the names won't clash with the names in blink, it should be easy to integrate them in blink later and fix issues, if needed.
BUG=
R=senorblanco@google.com, senorblanco@chromium.org, bsalomon@google.com, reed@google.com, mtklein@google.com
Author: sugoi@chromium.org
Review URL: https://chromiumcodereview.appspot.com/24157005
git-svn-id: http://skia.googlecode.com/svn/trunk@11475 2bbb7eff-a529-9590-31e7-b0007b416f81
This is a patch by Andrei Parvu <parvu@adobe.com> (Adobe CLA signer).
Original CL/review: https://codereview.chromium.org/24078006/
GM:lumamode will need rebaselining after landing this.
---
In order to use CSS luminance masking, we need to be able to create an
instance of SkLumaXfermode which can receive a kSrcOver mode, and applies
that mode after converting the source using the luminance-to-alpha
coefficients.
BUG=289420
R=reed@google.com
Review URL: https://codereview.chromium.org/23710053
git-svn-id: http://skia.googlecode.com/svn/trunk@11312 2bbb7eff-a529-9590-31e7-b0007b416f81
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
I also had to offset the matrix passed to filter evaluation by drawSprite() and internalDrawBitmap() by the primitive position. This is the same offset that is applied when drawing the primitive, to compensate for the internal saveLayer().
Also apply the total matrix to the filter params in asNewEffect(), so that (for example) lighting params are offset by both the compositor clipping and upstream crop rects.
R=reed@google.com
Review URL: https://codereview.chromium.org/23295017
git-svn-id: http://skia.googlecode.com/svn/trunk@10961 2bbb7eff-a529-9590-31e7-b0007b416f81
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
In order to preserve the immutability of SkImageFilters, the crop rect is passed as a constructor parameter. If NULL (the default), the bounds of the input image are used, as before.
This also tightens up the boundary handling for SkImageBlurFilter on the GPU backend. Where we were previously using clamping semantics, we now respect decal semantics (so we don't oversaturate the edges). This brings the GPU and raster backends into closer alignment, but will require some new baselines for the GPU tests.
At a minimum, the following tests will need new baselines: imageblur, imagefiltersbase, imagefilterscropped, spritebitmap.
R=reed@google.com
Committed: https://code.google.com/p/skia/source/detail?r=10251
Review URL: https://codereview.chromium.org/19775006
git-svn-id: http://skia.googlecode.com/svn/trunk@10338 2bbb7eff-a529-9590-31e7-b0007b416f81
In order to preserve the immutability of SkImageFilters, the crop rect is passed as a constructor parameter. If NULL (the default), the bounds of the input image are used, as before.
This also tightens up the boundary handling for SkImageBlurFilter on the GPU backend. Where we were previously using clamping semantics, we now respect decal semantics (so we don't oversaturate the edges). This brings the GPU and raster backends into closer alignment, but will require some new baselines for the GPU tests.
At a minimum, the following tests will need new baselines: imageblur, imagefiltersbase, imagefilterscropped, spritebitmap.
R=reed@google.com
Review URL: https://codereview.chromium.org/19775006
git-svn-id: http://skia.googlecode.com/svn/trunk@10251 2bbb7eff-a529-9590-31e7-b0007b416f81
This patch adds the parameter to the filterImageGPU() signature, plumbs through the code on the GPU side, and implements support for it in SkXfermodeImageFilter for both raster and GPU.
Of the remaining filters with GPU implementations, Blur, Morphology, Bicubic and Displacement work fine; they're commutative wrt offset and can simply pass it up the chain. Blend is not, but will be removed shortly anyway (has been replaced with SkXfermodeImageFilter in Blink).
R=reed@google.com, bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://chromiumcodereview.appspot.com/15995026
git-svn-id: http://skia.googlecode.com/svn/trunk@9977 2bbb7eff-a529-9590-31e7-b0007b416f81
For the raster path, we do a straightforward 2-pass method: draw background, then composite the foreground over it.
For the GPU path, if the xfermode can be expressed as an effect, we build an effect with the background texture incorporated, then do a single-pass draw fetching both foreground and background textures, and compositing to the result. If the xfermode is expressed as src/dst coefficients, we do a 2-pass draw as in the raster path and use fixed-function blending.
R=bsalomon@google.com, reed@google.com
Review URL: https://codereview.chromium.org/16125008
git-svn-id: http://skia.googlecode.com/svn/trunk@9373 2bbb7eff-a529-9590-31e7-b0007b416f81
Doing it this way required modifying the arithmode GM to use saveLayer()/restore() rather than creating an offscreen SkBitmap, since otherwise the compositing is always done in raster mode. Fixing that in turn exposed that SkArithmeticMode did not work in Picture mode, since it wasn't flattenable. Made it so.
Note: this will require rebaselining the arithmode GM (again).
R=bsalomon@google.com, reed@google.com
Review URL: https://codereview.chromium.org/16064002
git-svn-id: http://skia.googlecode.com/svn/trunk@9324 2bbb7eff-a529-9590-31e7-b0007b416f81
This new changelist also introduces a new image filter called SkRectShaderImageFilter which is make to simply apply a shader on a region without using any inputs.
TEST=Added ShaderImageFilter test
Review URL: https://codereview.appspot.com/7300046
git-svn-id: http://skia.googlecode.com/svn/trunk@7808 2bbb7eff-a529-9590-31e7-b0007b416f81
and handled that itself internally, rather than calling SkXfermode. This CL removes
the kModulate_Mode alias from its list.
git-svn-id: http://skia.googlecode.com/svn/trunk@7509 2bbb7eff-a529-9590-31e7-b0007b416f81
This fixes the bicubic image filter GM on the GPU, which otherwise draws garbage outside the filtered region. It also moves us closer to unifying the signatures of SkImageFilter::onFilterImage() and SkImageFilter::filterImageGPU().
Review URL: https://codereview.appspot.com/7180048
git-svn-id: http://skia.googlecode.com/svn/trunk@7467 2bbb7eff-a529-9590-31e7-b0007b416f81
Implement a bicubic resampling image filter, with raster and GPU backends.
In order to get this to work on the GPU side, I had to modify the width and height of the drawn texture in drawSprite() and drawDevice() to use the filtered texture's dimensions, instead of the source texture. (This wasn't a problem before since all other image filters produce results the same dimensions as their input texture.)
For now, this implementation only does axis-aligned scaling (same as the Lanczos-3 implementation in Chrome). It's also done for correctness and clarity, not speed, so there are lots of opportunities for speedups.
Committed: https://code.google.com/p/skia/source/detail?r=7275
Review URL: https://codereview.appspot.com/7033049
git-svn-id: http://skia.googlecode.com/svn/trunk@7287 2bbb7eff-a529-9590-31e7-b0007b416f81
In order to get this to work on the GPU side, I had to modify the width and height of the drawn texture in drawSprite() and drawDevice() to use the filtered texture's dimensions, instead of the source texture. (This wasn't a problem before since all other image filters produce results the same dimensions as their input texture.)
For now, this implementation only does axis-aligned scaling (same as the Lanczos-3 implementation in Chrome). It's also done for correctness and clarity, not speed, so there are lots of opportunities for speedups.
Review URL: https://codereview.appspot.com/7033049
git-svn-id: http://skia.googlecode.com/svn/trunk@7275 2bbb7eff-a529-9590-31e7-b0007b416f81
The separable blur algorithm gives +45% on SampleBlur, +84% on SampleBigBlur, +31% on TheVerge, +35 to +85% on blurbench in HQ (depending on size), +8 to +35% in low quality. (All of these on 32bit MacPro).
Review URL: https://codereview.appspot.com/6851117
git-svn-id: http://skia.googlecode.com/svn/trunk@6601 2bbb7eff-a529-9590-31e7-b0007b416f81
Search and replace:
GrCustomStage->GrEffect
GrCustomStageTestFactory->GrEffectTestFactory
renamed the cpp/h files from customStage->effect
reordered gypi, #includes, forward decls to maintain alphabetical sort.
manually fixed up some whitespace and linewraps
deleted a commented out #include
R=robertphillips@google.com
Review URL: https://codereview.appspot.com/6758046
git-svn-id: http://skia.googlecode.com/svn/trunk@6076 2bbb7eff-a529-9590-31e7-b0007b416f81
Existing filters which maintained their own filter connectivity were refactored to use the new constructors and flattening/unflattening code. Modifying the remaining filters which are not yet DAG-friendly is left for future work; they are considered to have zero inputs for now.
Review URL: https://codereview.appspot.com/6443119
git-svn-id: http://skia.googlecode.com/svn/trunk@5891 2bbb7eff-a529-9590-31e7-b0007b416f81
the premultiplying is done less efficiently than in the raster path: it's
done on each texture access, rather than as a pre-processing pass. This was
so I could do the filter as a single custom stage; will try the optimization
separately.
This implementation gives a ~30X speedup on the GPU results for the
matrixconvolution bench (~10X due to the GPU, and ~3X due to texture
uploads/readback removal).
Note: this changes the matrixconvolution for the software path as well, so
it will likely break the bots until that test is rebaselined.
Review URL: https://codereview.appspot.com/6585069/
git-svn-id: http://skia.googlecode.com/svn/trunk@5809 2bbb7eff-a529-9590-31e7-b0007b416f81
the matrix convolution filter. Test cases are added to the GM and the
bench.
NOTE: This will require rebaselining the matrixconvolution GM, so it will
likely turn the bots red until that is done.
https://codereview.appspot.com/6547049/
git-svn-id: http://skia.googlecode.com/svn/trunk@5661 2bbb7eff-a529-9590-31e7-b0007b416f81
