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
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
This also includes some changes to the xfermodeimagefilter and tileimagefilter GMs to properly handle the CTM. This worked before only because SkBitmapSource was ignoring the CTM. Now that it respects it, we need to give the correct transform. This also means the GMs now work while zoomed. It also implements CTM support for SkTileImageFilter.
NOTE: this will require rebaselining a number of imagefilter GMs on Nexus4, since they render in perspective (using the CTM). The changes to the results should all be improvements.
R=reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/106933002
git-svn-id: http://skia.googlecode.com/svn/trunk@12571 2bbb7eff-a529-9590-31e7-b0007b416f81
Note: I initially implemented this as a fully-generic SkResizeImageFilter, but then I realized that the dstRect should always be transformed by the filter matrix, but that the srcRect should not (since it's specified relative to the dimensions of the original bitmap). Since this would be confusing for someone attempting to use this as a generic resizing filter, I decided to build the functionality into SkBitmapSource instead.
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/106933002
git-svn-id: http://skia.googlecode.com/svn/trunk@12522 2bbb7eff-a529-9590-31e7-b0007b416f81
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
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
