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
is templated on the tiling mode for speed: interior pixels are unconditionally
fetched; border pixels apply the appropriate tiling mode before fetching. It
handles target, bias, divisor (as gain), and edge modes (named to be more
skia-like). It does not handle the "preserveAlpha" semantics of
feConvolveMatrix, nor "kernelUnitLength".
git-svn-id: http://skia.googlecode.com/svn/trunk@5592 2bbb7eff-a529-9590-31e7-b0007b416f81
Move Line2DPathEffect (now Sk_) into a separate header file so it can
be shared and initialized.
Switch to the shared version in SampleAll and SampleSlides.
Remove the skip pipe flag from texteffects, since it can now be serialized.
I have a separate change to turn serialization on by default at https://codereview.appspot.com/6498121/
Review URL: https://codereview.appspot.com/6503106
git-svn-id: http://skia.googlecode.com/svn/trunk@5512 2bbb7eff-a529-9590-31e7-b0007b416f81
element. This filter has two inputs, since normal blending can't be used. The
GPU side uses two filter stages to accomplish this: one to sample the
background, and one to sample the foreground and blend it.
Review URL: https://codereview.appspot.com/6463081/
git-svn-id: http://skia.googlecode.com/svn/trunk@5231 2bbb7eff-a529-9590-31e7-b0007b416f81
for filters with a single image input. This provides functionality to store,
flatten and unflatten a single SkImageFilter input, as well as to recursively
evaluate it on the CPU or GPU. The following classes were re-parented to
implement DAG connectivity: SkBlurImageFilter, SkDilateImageFilter,
SkErodeImageFilter, SkColorFilterImageFilter. The constructors for each
have been appended with a new parameter, representing the input filter
(default NULL).
This change also implements an arbitrary SkBitmap input source for filtering,
SkBitmapSource.
NOTE: This CL will require gyp file changes when rolling past this revision.
Review URL: https://codereview.appspot.com/6462071/
git-svn-id: http://skia.googlecode.com/svn/trunk@5170 2bbb7eff-a529-9590-31e7-b0007b416f81
This CL is an effort to stage the conversion to named
parameters for all SkFlattenable commands. This particular
stage only does the following two things...
1. Move flattenable buffers from SkFlattenable.h into
their own header.
2. Update and Add new read write methods for better clarity
and convenience.
BUG=
Review URL: https://codereview.appspot.com/6448095
git-svn-id: http://skia.googlecode.com/svn/trunk@4980 2bbb7eff-a529-9590-31e7-b0007b416f81
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
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
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
called (for now at least) TwoPointConical, to distinguish it from the
existing one (TwoPointRadial), and to reflect its odd behavior where it draws
transparent outside the boundary of the "cone" between the two circles.
This impl is unsupported by GPU and Printing at the moment, and Chrome does not
yet invoke it.
Review URL: https://codereview.appspot.com/6299051
git-svn-id: http://skia.googlecode.com/svn/trunk@4197 2bbb7eff-a529-9590-31e7-b0007b416f81
or stroke parameters for a path.
Today, the patheffect only sees if the caller was going to stroke or fill, and
if stroke, it just sees the width. With this change, the effect can see all of the
related parameters (e.g. cap/join/miter). No other change is intended at this
time.
After this change, I hope to use this additional data to allow SkDashPathEffect
to, at times, apply the stroke as part of its effect, which may be much more
efficient than first dashing, and then reading that and stroking it.
Most of these files changed just because of the new parameter to filterPath. The
key changes are in SkPathEffect.[h,cpp], SkPaint.cpp and SkScalerContext.cpp
Review URL: https://codereview.appspot.com/6250051
git-svn-id: http://skia.googlecode.com/svn/trunk@4048 2bbb7eff-a529-9590-31e7-b0007b416f81
or stroke parameters for a path.
Today, the patheffect only sees if the caller was going to stroke or fill, and if
stroke, it just sees the width. With this change, the effect can see all of the
related parameters (e.g. cap/join/miter). No other change is intended at this
time.
After this change, I hope to use this additional data to allow SkDashPathEffect
to, at times, apply the stroke as part of its effect, which may be much more
efficient than first dashing, and then reading that and stroking it.
Most of these files changed just because of the new parameter to filterPath. The
key changes are in SkPathEffect.[h,cpp], SkPaint.cpp and SkScalerContext.cpp
Review URL: https://codereview.appspot.com/6249050
git-svn-id: http://skia.googlecode.com/svn/trunk@4046 2bbb7eff-a529-9590-31e7-b0007b416f81
