This macro was responsible for producing code like:
static SkAlignedStorage<sizeof(Foo)> g_gFoo_Storage;
static Foo* gFoo = new(g_gFoo_Storage.get()) Foo;
static SkAutoTDestroy<Foo> gFoo_ad(gFoo);
which would allocate static storage for an object of type Foo
(g_gFoo_Storage), lazily instantiate the object in that memory (via
gFoo's initializer), and then ensure that at global destruction time
the object is destroyed (via gFoo_Ad's destructor).
However, the exact same effect is achieved by just writing:
static Foo gFoo;
Review URL: https://codereview.chromium.org/1314763009
The CPU path for lighting image filters was not adjusting the filter
matrix to accommodate srcOffset, resulting in incorrectly-positioned
lights. (The GPU path was doing this correctly.)
This change adds a new test case to the imagefiltersclipped GM,
so it will need new baselines.
BUG=skia:
Review URL: https://codereview.chromium.org/1310053004
SkXfermodeImageFilter::filterImageGPU is the only call site that does anything fancy when getInputResultsGPU fails. It seems like we can just return like everyone else (for uniformity).
Review URL: https://codereview.chromium.org/1302033004
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/+/915881fe743f9a789037695f543bc6ea189cd0cbTBR=reed@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=4212
Review URL: https://codereview.chromium.org/1300403003
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
SkTemplates.h contains a number of Skia specific utilities which are
not designed for external use. In addition to reducing the external
support burden, this will allow Skia to freely refactor this file.
Review URL: https://codereview.chromium.org/1272293004
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)
Review URL: https://codereview.chromium.org/1291783003
Nothing too fancy.
Direction enums become enum classes so they don't get all confused. An
alternative is to create one single Direction enum that both blur and
morphology opts use.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1267343004
+268 -535 lines
I also rearranged the code a little bit to encapsulate itself better,
mostly replacing static helper functions with lambdas. This also
let me merge the SSE2 and SSE4.1 code paths.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1264103004
Additionally this CL:
forces the light colors to be opaque
forces the light direction to be normalized
adds a raster implementation
adds a gm
Review URL: https://codereview.chromium.org/1245883003
This is split off of https://codereview.chromium.org/1225923010/ (Start tightening correspondence betweeen GrDrawContext and GrRenderTarget). It:
fixes some style nits
replaces some passing of GrContext with GrTextureProvider & GrDrawContext
does a bit of the finer grained creation of GrDrawContexts
Review URL: https://codereview.chromium.org/1245183002
The normalize routine in SkPoint3 is very robust. However, for simple
lighting cases we prefer speed over robustness. This fixes a perf
regression in smoothness.tough_filters_cases.
BUG=chromium:510562
Review URL: https://codereview.chromium.org/1240023002
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
The purpose is to begin separating our GLSL-specific code from
our GL-specific code, so it can be used with the GL45 platform
Review URL: https://codereview.chromium.org/1202293002
This CL continues cleaning up Skia's usage of SkSurfaceProps. It:
Removes the duplicate SkSurfaceProps object from SkImageFilter::Proxy.
Removes a dispreferred ctor from SkCanvas
Removes the initForRootLayer entry point from SkDevice (since the root device and the canvas should always have the same pixel geometry now).
Review URL: https://codereview.chromium.org/1201983006
I haven't figured out a pithy way to have these apply to only classes
originating from SkNx, so let's just remove them. There aren't too
many use cases, and it's not really any less readable without them.
Semantically, this is a no-op.
BUG=skia:
Review URL: https://codereview.chromium.org/1167153002
Moves the coverage logic into GrGLXferProcessor for XPs that perform
dst reads. XPs that don't use a dst read are still responsible to
handle coverage on their own.
BUG=skia:
Review URL: https://codereview.chromium.org/1170553002
Reason for revert:
Blink
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
>
> Committed: https://skia.googlesource.com/skia/+/0be685755f942baea26c66a87226b569fc17e960TBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1156583004
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
Review URL: https://codereview.chromium.org/1152553006
Reason for revert:
breaking tests
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4eTBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1143083006
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Review URL: https://codereview.chromium.org/1152553006
Renames getInvariantOutput to getInvariantBlendedColor on GrXPFactory
and redefines it to not account for coverage conflation. This is the
information that all the callsites actually wanted to know.
BUG=skia:
Review URL: https://codereview.chromium.org/1161273005
GrGpu, GrGLGpu, GrPathRendering, GrGLPathRendering all duplicated
each others' path rendering related member functions. Make
GrPathRending the logical extension of GrGpu by removing the methods
from GrGpu. Similarly to the GL variants.
Changes includes and forward declarations due to removing
GrDrawTarget.h include from GrGpu.h. This was necessary due to
GrDrawTarget.h including GrPathRendering.h, and now GrPathRendering.h
includes GrGpu.h. (Also GrGpu.h does not need GrDrawTarget.h anymore).
Very slight runtime improvement on x86_64:
desk_fontwipe.skp_1 836us -> 841us 1.01x
desk_silkfinance.skp_1 2.01ms -> 2.01ms 1x
desk_forecastio.skp_1 7.03ms -> 7.05ms 1x
desk_weather.skp_1 3.74ms -> 3.74ms 1x
desk_twitter.skp_1 8.02ms -> 8.01ms 1x
desk_mapsvg.skp_1 5.24ms -> 5.23ms 1x
desk_pokemonwiki.skp_1 7.06ms -> 7.03ms 1x
desk_sfgate.skp_1 3.19ms -> 3.17ms 1x
tabl_cuteoverload.skp_1 2.66ms -> 2.64ms 0.99x
...
tabl_transformice.skp_1 3.06ms -> 2.98ms 0.98x
tabl_googlecalendar.skp_1 11.3ms -> 11ms 0.97x
tabl_gamedeksiam.skp_1 12.8ms -> 12.4ms 0.97x
desk_samoasvg.skp_1 10.6ms -> 10.3ms 0.97x
tabl_worldjournal.skp_1 4.44ms -> 4.3ms 0.97x
Review URL: https://codereview.chromium.org/1157683006
This is mainly a mechanical CL. There were some fiddly bits in GrContext.cpp where it no longer had access to the GrDrawTarget (and had to use the new GrDrawContext).
I've converted GrAARectRenderer & GrOvalRenderer into static classes so I could stop allocating them.
Review URL: https://codereview.chromium.org/1151283004
If one of the inputs to a SkMergeImageFilter was clipped away or
otherwise caused the filterImage(...) invocation for it to return
false, the entire effect would be "failed" and return false --
regardless of if it had produced a result or not.
Instead of returning false directly if filterImage(...) for a source
returned false, consider all the inputs, and then only return false if
all of them do.
BUG=chromium:489046
Review URL: https://codereview.chromium.org/1133523006
Effectively all this does is future-proof any GLSL-specific code, as
GLSLCaps is just a typedef of GLCaps.
BUG=skia:
Review URL: https://codereview.chromium.org/1109863004
Reason for revert:
MIPS
Original issue's description:
> De-proc Color32
>
> Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
> which is no longer needed.
>
> Seems handy to have SkTypes include the relevant intrinsics when
> we know we've got them, but I'm not married to it.
>
> Locally this looks like a pointlessly small perf win, but I'm mostly
> keen to get all the code together.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72bTBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1108163002
Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
which is no longer needed.
Seems handy to have SkTypes include the relevant intrinsics when
we know we've got them, but I'm not married to it.
Locally this looks like a pointlessly small perf win, but I'm mostly
keen to get all the code together.
BUG=skia:
Review URL: https://codereview.chromium.org/1104183004
patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs
On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.8-Clang-Arm7-Debug-Android-Trybot,Build-Ubuntu-GCC-Arm7-Release-Android_NoNeon-Trybot
Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ec
Review URL: https://codereview.chromium.org/1109643002
Reason for revert:
compile failures.
Original issue's description:
> Mike's radial gradient CL with better float -> int.
>
> patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
>
> This looks quite launchable. radial_gradient3, min of 100 samples:
> N5: 985µs -> 946µs
> MBP: 395µs -> 279µs
>
> On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
>
> BUG=skia:
>
> CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ecTBR=reed@google.com,robertphillips@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1109883003
patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs
On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
Review URL: https://codereview.chromium.org/1109643002
Adds an onGetBlendInfo method for GrXferProcessor subclasses to
override instead of overriding getBlendInfo directly. This gives the
base class a chance to initialize the struct with default values
before passing it on. As the BlendInfo struct grows, this will keep
things simple and less error prone.
BUG=skia:
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1049143002
This CL also adds a new parameter to SkBitmapSource which gives the user control of the filter quality.
BUG=472795
Review URL: https://codereview.chromium.org/1072603002
approx-match.
This revealed some further 0..1 texture coordinate
depedencies,specifically in SkDisplacementMapEffect and
SkXfermodeImageFilter, fixed through use of
GrTextureDomain.
Note: causes minor pixel diffs in pictureimagefilter,
testimagefilters GMs.
Also causes minor pixel diffs in some Blink layout tests,
suppressed here: https://codereview.chromium.org/1064943002
BUG=skia:3532
Review URL: https://codereview.chromium.org/1065683002
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c
Review URL: https://codereview.chromium.org/1034733002
Reason for revert:
Spoke to Stephen about this. Reverting because failing debug builds:
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug/builds/51https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/54
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter, SkMatrixConvolutionImageFilter,
> SkMatrixImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> For the SkMatrixConvolutionImageFilter, it seems the
> GLSL clamp() function occasionally returns values outside
> the clamped range, resulting in access of garbage
> texels even in GL_NEAREST. The fix here is to clamp to a
> rect inset by half a texel. There was also a bug in
> the unpremultiply step when fConvolveAlpha is false.
>
> For SkMatrixImageFilter, the fix was to make the generic
> draw path be more careful about when to use texture domain.
> If the bitmap already has a texture, use texture domain
> if the srcRect is smaller than the entire texture (not
> the entire bitmap).
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
>
> Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460cTBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057693002
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Review URL: https://codereview.chromium.org/1034733002
Reason for revert:
Looks like this change is causing layout test failures which is blocking Skia's DEPS roll into Chromium:
https://codereview.chromium.org/1050563002/https://codereview.chromium.org/1043133005/https://codereview.chromium.org/1048273002/
Reverting to see if this fixes the DEPS roll.
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641TBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057443003
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Review URL: https://codereview.chromium.org/1034733002
The primary feature this delivers is SkNf and SkNd for arbitrary power-of-two N. Non-specialized types or types larger than 128 bits should now Just Work (and we can drop in a specialization to make them faster). Sk4s is now just a typedef for SkNf<4, SkScalar>; Sk4d is SkNf<4, double>, Sk2f SkNf<2, float>, etc.
This also makes implementing new specializations easier and more encapsulated. We're now using template specialization, which means the specialized versions don't have to leak out so much from SkNx_sse.h and SkNx_neon.h.
This design leaves us room to grow up, e.g to SkNf<8, SkScalar> == Sk8s, and to grown down too, to things like SkNi<8, uint16_t> == Sk8h.
To simplify things, I've stripped away most APIs (swizzles, casts, reinterpret_casts) that no one's using yet. I will happily add them back if they seem useful.
You shouldn't feel bad about using any of the typedef Sk4s, Sk4f, Sk4d, Sk2s, Sk2f, Sk2d, Sk4i, etc. Here's how you should feel:
- Sk4f, Sk4s, Sk2d: feel awesome
- Sk2f, Sk2s, Sk4d: feel pretty good
No public API changes.
TBR=reed@google.com
BUG=skia:3592
Review URL: https://codereview.chromium.org/1048593002
Currently, the GPU-side image filter implementation creates exact-match
textures for the offscreen backing stores for saveLayer(). This is
because several filters have GPU implementations which depend on the
texture coordinates being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so that when
wrapping it in an SkBitmap for passing to filterImage(), we can give
it the original size.
2) Fix the filters (SkMagnifierImageFilter, more TBD) whose GPU
implementation depends on 0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Review URL: https://codereview.chromium.org/1034733002
(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
Clarify asColorFilter ...
1. Rename to isColorFilterNode for DAG reduction
2. Add asAColorFilter for removing the imagefilter entirely (future use-case)
Need layouttest rebaseline suppression before this can land in chrome...
https://codereview.chromium.org/984023004/
BUG=skia:
Review URL: https://codereview.chromium.org/982933002
Reason for revert:
Need to suppress these for rebaselining, so reverting for now.
Regressions: Unexpected image-only failures (5)
css3/filters/effect-brightness-clamping-hw.html [ ImageOnlyFailure ]
css3/filters/effect-combined-hw.html [ ImageOnlyFailure ]
virtual/slimmingpaint/css3/filters/effect-brightness-clamping-hw.html [ ImageOnlyFailure ]
virtual/slimmingpaint/css3/filters/effect-combined-hw.html [ ImageOnlyFailure ]
Original issue's description:
> Use ComposeColorFilter in factory to collapse consecutive filters (when possible).
> Change asColorFilter to reflect its reliance on the new factory behavior.
>
> patch from issue 967143002 at patchset 80001 (http://crrev.com/967143002#ps80001)
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/dac843bf046c2cd79fd955cb177aee241d7a4b0cTBR=senorblanco@chromium.org,robertphillips@google.com,bsalomon@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/978923005
This makes SkComposeImageFilter::computeFastBounds compose its
filters' bounds (rather than falling back to
SkImageFilter::computeFastBounds, which takes the union of the bounds).
This also makes SkComposeImageFilter::onFilterImage correctly handle
an offset produced when applying the inner filter; such offsets were
previously ignored.
BUG=chromium:453924
Review URL: https://codereview.chromium.org/908273002
BUG=skia:1366
For the added bench, the collapsing makes the bench take:
- 70% of the time for CPU rendering of 3 consecutive matrix filters
- almost no change in the GPU rendering of the matrix filters
- 50% of the time for CPU and GPU rendering of 3 consecutive table filters
Review URL: https://codereview.chromium.org/776673002
