Commit Graph

54 Commits

Author SHA1 Message Date
Mike Reed
607a382298 drawBitmap is deprecated, use drawImage
Change-Id: Ib66517fe26036704ccb8328ef92fa0f5240c79f4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358222
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
2021-01-25 01:44:55 +00:00
Michael Ludwig
f577427888 Fix lighting image filters
1. Removes clamping of spotlight's specular exponent, which is not the
   specified behavior of feSpotLight in SVG.
   (note: we never clamped a specular lighting effect's
    specular exponent/shininess parameter, although SVG 1.1 does clamp
    that; that is the client's responsibility).
2. Fixes a bug in the GPU implementation of scale factor for spot lights.
3. Saturate computed lighting color after multiplying with color scale,
   instead of just saturating the color scale (allows high intensity
   lights to saturate to white which is more reasonable approximation of
   an HDR effect stored in an LDR color).

Note: fixes 1 and 2 were originally addressed in https://bugs.chromium.org/p/chromium/issues/detail?id=472849
but the change was reverted for layout failure reasons and it was never
relanded after rebasing.

Note2: most of the layout test rebaselines necessary for chrome are
minor and related to fix 2. The exception is svg/dynamic-updates/SVGFESpecularLightingElement-dom-kernelUnitLength-attr.html
which is the result of fix 3. It took a little digging, but I believe
that fix 3 actually makes that generated SVG more correct (it's original
expected image was "wrong").

In that test, it has a specular constant of 4 (which is a multiplier)
and a shininess of 1 (which makes it practically a "diffuse" specular).
So basically we are multiplying the greenYellow color by 4 for most of
the image that has a normal pointing out of the screen. Firefox renders
a similarly yellow oversaturated appearance instead of clamping to the
base greenYellow.

Reading the feSpecularLighting spec, there is no saturation that is
specified where it had been performed before this change. Instead, all
that is mentioned is that the results of a given filter have to be pinned
to the color channel range (e.g. the last step).

Bug: skia:11007, skia:11057, skia:11153
Change-Id: I82e4a6f1742fecea59816fda75eb931c2a51d3e1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/355496
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2021-01-22 20:13:48 +00:00
John Stiles
7571f9e490 Replace 'typedef xxxxx INHERITED' with 'using INHERITED = xxxx;'.
Mechanically updated via Xcode "Replace Regular Expression":

  typedef (.*) INHERITED;
    -->
  using INHERITED = $1;

The ClangTidy approach generated an even larger CL which would have
required a significant amount of hand-tweaking to be usable.

Change-Id: I671dc9d9efdf6d60151325c8d4d13fad7e10a15b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314999
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
2020-09-03 03:41:26 +00:00
John Stiles
a6841be235 Enable ClangTidy check llvm-namespace-comment.
This fixes a large number of SkSL namespaces which were labeled as if
they were anonymous, and also a handful of other mislabeled namespaces.
Missing namespace-end comments have been added throughout.
A number of diffs are just indentation-related (adjusting 1- or 3-
space indents to 2-space).

Change-Id: I6c62052a0d3aea4ae12ca07e0c2a8587b2fce4ec
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/308503
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
2020-08-06 19:07:52 +00:00
Michael Ludwig
898bbfac2e Update gms to use new image filter factories
Bug: skia:9280
Change-Id: Ic7ca3a9c86025128bc45b89ea90aa4553287b8c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/230879
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
2019-08-02 21:08:40 +00:00
Hal Canary
41248071ac tools: separate TimeUtils from AnimTimer
gm, slides, and samples no longer need to know about the implementation
details of AnimTimer.

This
    virtual bool onAnimate(const AnimTimer&);
becomes this:
    virtual bool onAnimate(double /*nanoseconds*/);
which is much easier to reason about.

AnimTimer itself is now part of viewer.

Change-Id: Ib70bf7a0798b1991f25204ae84f70463cdbeb358
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/226838
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
2019-07-12 15:05:01 +00:00
Ben Wagner
7fde8e1728 IWYU for gms.
This almost gets gms to be iwyu clean. The last bit is around gm.cpp
and the tracing framework and its use of atomic. Will also need a way
of keeping things from regressing, which is difficult due to needing to
do this outside-in.

Change-Id: I1393531e99da8b0f1a29f55c53c86d53f459af7d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/211593
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
2019-05-02 17:48:53 +00:00
Mike Klein
c0bd9f9fe5 rewrite includes to not need so much -Ifoo
Current strategy: everything from the top

Things to look at first are the manual changes:

   - added tools/rewrite_includes.py
   - removed -Idirectives from BUILD.gn
   - various compile.sh simplifications
   - tweak tools/embed_resources.py
   - update gn/find_headers.py to write paths from the top
   - update gn/gn_to_bp.py SkUserConfig.h layout
     so that #include "include/config/SkUserConfig.h" always
     gets the header we want.

No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
2019-04-24 16:27:11 +00:00
Brian Osman
4428f2c39f Remove SkScalarSinCos
This differed from the separate versions in that it snapped to zero.
It was also strictly worse than calling the two separate versions.
Most clients don't need the snapping, so just call the two existing
functions. For clients that need the snapping, call new variants of
each that do snap.

Change-Id: Ia4e09fd9651932fe15caeab1399df7f6281bdc17
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/205303
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
2019-04-02 15:46:57 +00:00
Mike Klein
cd5104e942 SkAnimTimer -> AnimTimer
Change-Id: I700b7c0461475062ac66712cc29070f150cf777d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202315
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2019-03-20 18:26:35 +00:00
Mike Klein
ea3f014e2b sk_tool_utils -> ToolUtils, and git clang-format
sk_tool_utils doesn't really fit the naming convention
the rest of code under tools/ tends to use.

Change-Id: I45326a174101c6eb4b6149e9c742f658f2fd23b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202313
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2019-03-20 18:05:42 +00:00
Mike Klein
d46dce3de5 don't adapt any gray colors to 565
Adapting gray to 565 will add a noticeable purple/green tint.
I'd rather only the 565 images in Gold were tainted with that.

Change-Id: Ib09e92b2f78c6de086345124e9eefeb31bbb5fa8
Reviewed-on: https://skia-review.googlesource.com/147422
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2018-08-16 19:13:41 +00:00
Mike Klein
33d2055e59 GM: some header cleanup
gm.h includes sk_tool_utils.h but does not use it.

The bulk of this CL makes each gm that uses sk_tool_utils include it.

sk_tool_utils.h also provided SkRandom and SkTDArray,
so a couple GMs add those headers too.

Change-Id: Ieb2a7c542f0ca89c3223f744fc11b0ff37af36c1
Reviewed-on: https://skia-review.googlesource.com/10014
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
2017-03-22 18:11:49 +00:00
Mike Reed
df85c38163 stop using SkScalarMul
BUG=skia:

Change-Id: Ie41d8665a1c62ba8eddc93d8cfefaf64ddc52ff8
Reviewed-on: https://skia-review.googlesource.com/8411
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
2017-02-14 19:45:24 +00:00
mtklein
dbfd7ab108 Replace a lot of 'static const' with 'constexpr' or 'const'.
'static const' means, there must be at most one of these, and initialize it at
compile time if possible or runtime if necessary.  This leads to unexpected
code execution, and TSAN* will complain about races on the guard variables.

Generally 'constexpr' or 'const' are better choices.  Neither can cause races:
they're either intialized at compile time (constexpr) or intialized each time
independently (const).

This CL prefers constexpr where possible, and uses const where not.  It even
prefers constexpr over const where they don't make a difference... I want to have
lots of examples of constexpr for people to see and mimic.

The scoped-to-class static has nothing to do with any of this, and is not changed.

* Not yet on the bots, which use an older TSAN.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300623005

Review-Url: https://codereview.chromium.org/2300623005
2016-09-01 11:24:54 -07:00
robertphillips
12fa47d33f Update LightingImageFilter to sk_sp
TBR=reed@google.com

GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1869763002

Review URL: https://codereview.chromium.org/1869763002
2016-04-08 16:28:09 -07:00
robertphillips
651bb5fafe Make some GMs animate
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1870133003

Review URL: https://codereview.chromium.org/1870133003
2016-04-08 13:35:14 -07:00
robertphillips
51a315eff9 Update SkOffsetImageFilter to sk_sp
TBR=reed@google.com

GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1842193002

Review URL: https://codereview.chromium.org/1842193002
2016-03-31 09:05:49 -07:00
caryclark
0bccd8749b Revert of Update feSpotLight to match spec (patchset id:20001 of https://codereview.chromium.org/1403403003/ )
Reason for revert:
re-land once layout test have been disabled (so they can be rebased)

Original issue's description:
> Update feSpotLight to match spec
>
> This change updates feSpotLight to match the spec via two changes:
>
> 1) specularExponent is ignored if the spotlight has no coneAngle (GPU
>    bug only). This change updates the GPU path so that it matches the
>    CPU path and the spec in this regard.
>
> 2) specularExponent is clamped to the 1-128 range. The spec does not
>    specify a clamp for the specularExponent attribute of feSpotLight.
>    Note that the spec *does* specify this clamp for the
>    specularExponent attribute of feSpecularLighting. It looks like we
>    incorrectly applied this to both specularExponent attributes.
>
>    This change (along with a parallel change in Blink) allows us to pass
>    the SVG filter effects conformance test here:
>    http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/filters-light-01-f.html
>
>    Additionally, this brings our behavior in line with Safari and Edge’s
>    behavior on this filter.
>
> Two new cases were added to gm/lighting.cpp to catch these issues:
> - The existing spotlight case exercised the path where our specular
>   exponent was between 1-128 and had a limiting cone angle.
> - The first new spotlight case exercises the path where our specular
>   exponent is between 1-128 and we do not have a limiting cone angle.
> - The second new spotlight case exercises the path where the specular
>   exponent is not within the 1-128 range, to ensure that we don’t
>   incorrectly clip to this range.
>
> BUG=472849
>
> Committed: https://skia.googlesource.com/skia/+/c84ccb070258db2803a9e8f532bfe7239a737063

TBR=senorblanco@google.com,senorblanco@chromium.org,bsalomon@google.com,ericrk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=472849

Review URL: https://codereview.chromium.org/1417463006
2015-10-20 10:04:03 -07:00
ericrk
c84ccb0702 Update feSpotLight to match spec
This change updates feSpotLight to match the spec via two changes:

1) specularExponent is ignored if the spotlight has no coneAngle (GPU
   bug only). This change updates the GPU path so that it matches the
   CPU path and the spec in this regard.

2) specularExponent is clamped to the 1-128 range. The spec does not
   specify a clamp for the specularExponent attribute of feSpotLight.
   Note that the spec *does* specify this clamp for the
   specularExponent attribute of feSpecularLighting. It looks like we
   incorrectly applied this to both specularExponent attributes.

   This change (along with a parallel change in Blink) allows us to pass
   the SVG filter effects conformance test here:
   http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/filters-light-01-f.html

   Additionally, this brings our behavior in line with Safari and Edge’s
   behavior on this filter.

Two new cases were added to gm/lighting.cpp to catch these issues:
- The existing spotlight case exercised the path where our specular
  exponent was between 1-128 and had a limiting cone angle.
- The first new spotlight case exercises the path where our specular
  exponent is between 1-128 and we do not have a limiting cone angle.
- The second new spotlight case exercises the path where the specular
  exponent is not within the 1-128 range, to ensure that we don’t
  incorrectly clip to this range.

BUG=472849

Review URL: https://codereview.chromium.org/1403403003
2015-10-19 14:44:56 -07:00
robertphillips
943a462fef Minor code cleanup (left over from prior CL)
This was requested in https://codereview.chromium.org/1309543012/ (Add new GM to directly exercise perspective bitmap drawing)

Review URL: https://codereview.chromium.org/1320673011
2015-09-03 13:32:33 -07:00
halcanary
96fcdcc219 Style Change: NULL->nullptr
DOCS_PREVIEW= https://skia.org/?cl=1316233002

Review URL: https://codereview.chromium.org/1316233002
2015-08-27 07:41:16 -07:00
halcanary
385fe4d4b6 Style Change: SkNEW->new; SkDELETE->delete
DOCS_PREVIEW= https://skia.org/?cl=1316123003

Review URL: https://codereview.chromium.org/1316123003
2015-08-26 13:07:49 -07:00
robertphillips
5f865b9cf1 Move LightingShader to effects
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
2015-07-29 12:28:04 -07:00
caryclark
125960152d make tests portable by using 565 compatible colors
TBR=reed@google.com

Review URL: https://codereview.chromium.org/1262703002
2015-07-29 05:27:47 -07:00
caryclark
1818acb6a4 rename portable_typeface_always to portable_typeface
TBR=reed@google.com

Review URL: https://codereview.chromium.org/1257773002
2015-07-24 12:09:25 -07:00
caryclark
97a26d04e2 make drawbitmaprect lighting lumafilter matrixconvolution srcmode gm portable
TBR=reed@google.com

Review URL: https://codereview.chromium.org/1240843005
2015-07-17 13:20:48 -07:00
robertphillips
3d32d768cd Add new SkPoint3 class
The existing Light filter and the upcoming Lighting Shader both need a Point3 class

Review URL: https://codereview.chromium.org/1229693009
2015-07-13 13:16:44 -07:00
senorblanco
d0d37cace0 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/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c

Review URL: https://codereview.chromium.org/1034733002
2015-04-02 04:54:57 -07:00
rmistry
82973dbf4f Revert of Implement approx-match support in image filter saveLayer() offscreen. (patchset id:590001 of 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/51
https://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/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c

TBR=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
2015-04-01 15:53:13 -07:00
senorblanco
46112cf2a7 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

Review URL: https://codereview.chromium.org/1034733002
2015-04-01 14:17:14 -07:00
rmistry
7c0273f107 Revert of Implement approx-match support in image filter saveLayer() offscreen. (patchset id:510001 of 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/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641

TBR=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
2015-04-01 04:19:45 -07:00
senorblanco
f5f8518fe0 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

Review URL: https://codereview.chromium.org/1034733002
2015-03-31 08:35:16 -07:00
mtklein
36352bf5e3 C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}
NOPRESUBMIT=true

BUG=skia:
DOCS_PREVIEW= https://skia.org/?cl=1037793002

Review URL: https://codereview.chromium.org/1037793002
2015-03-25 18:17:32 -07:00
mtklein
1c4029296f remove unused GM flags
Depends on https://codereview.chromium.org/873753002/

Thumbs up to CLion for refactoring this for me.

BUG=skia:

Review URL: https://codereview.chromium.org/867963004
2015-01-23 11:07:08 -08:00
mtklein
72c9faab45 Fix up all the easy virtual ... SK_OVERRIDE cases.
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
2015-01-09 10:06:40 -08:00
tfarina
752e7eb157 Cleanup: Another round of override fixes.
BUG=skia:3075
TEST=ninja -C out/Debug
TBR=mtklein@google.com

Review URL: https://codereview.chromium.org/815883002
2014-12-20 06:53:43 -08:00
Cary Clark
992c7b03ef Add standard fonts to all GMs.
Allow GM results to be compared across machines and platforms by
standardizing the fonts used by all tests.

This adds runtime flags to DM to use either the system font context (the
default), the fonts in the resources directory ( --resourceFonts ) or a set
of canonical paths generated from the fonts ( --portableFonts ).

This CL should leave the current DM results unchanged by default.

If the portable font data or resource font is missing when DM is run, it
falls back to using the system font context.

The create_test_font tool generates the paths and metrics read by DM
with the --portableFonts flag set, and generates the font substitution
tables read by DM with the --resourceFonts flag set.

If DM is run in SkDebug mode with the --reportUsedChars flag set, it
generates the corresponding data compiled into the create_test_font tool.

All GM tests set their typeface information by calling either

  sk_tool_utils::set_portable_typeface or
  sk_tool_utils::portable_typeface .

(The former takes the paint, the latter returns a SkTypeface.) These calls
can be removed in the future when the Font Manager can be superceded.

BUG=skia:2687
R=mtklein@google.com

Review URL: https://codereview.chromium.org/407183003
2014-07-31 08:58:44 -04:00
commit-bot@chromium.org
a90c680386 Turn on quilt mode in DM.
- Rename TileGrid -> Quilt to avoid the name overload.
  - Tag all failing GMs with kSkipTiled_Flag.

You may be wondering, do any GMs pass?  Yes, some do!  And that trends towards all of them as we increase --quiltTile.

Two GMs only fail in --quilt mode in 565.  Otherwise all GMs which fail are skipped, and those which don't fail aren't. (The 8888 variants of those two GMs are skipped even though they pass.)

BUG=skia:2477
R=reed@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/256373002

git-svn-id: http://skia.googlecode.com/svn/trunk@14457 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-04-30 13:20:45 +00:00
commit-bot@chromium.org
c3bd8af6d5 add peekPixels to SkCanvas and SkSurface
fix reference to SkBaseDevice, which was only a problem in no-gpu build

This reverts commit 4fa44a6bf73891b21917fb90d02beef9143bffa3.

R=reed@google.com

Author: reed@chromium.org

Review URL: https://codereview.chromium.org/163603003

git-svn-id: http://skia.googlecode.com/svn/trunk@13432 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-02-13 17:14:46 +00:00
commit-bot@chromium.org
bda591c739 Revert of add peekPixels to SkCanvas and SkSurface (https://codereview.chromium.org/161733002/)
Reason for revert:
compile issues with gm/xfermodes3

Original issue's description:
> add peekPixels to SkCanvas and SkSurface
>
> clone of https://codereview.chromium.org/159723006/
>
> Committed: https://code.google.com/p/skia/source/detail?r=13427

R=jvanverth@google.com
NOTREECHECKS=true
NOTRY=true

Author: reed@chromium.org

Review URL: https://codereview.chromium.org/163823002

git-svn-id: http://skia.googlecode.com/svn/trunk@13428 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-02-13 15:29:03 +00:00
mike@reedtribe.org
b2d93a9122 add peekPixels to SkCanvas and SkSurface
clone of https://codereview.chromium.org/159723006/

Review URL: https://codereview.chromium.org/161733002

git-svn-id: http://skia.googlecode.com/svn/trunk@13427 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-02-13 15:11:11 +00:00
reed@google.com
eb9a46cbbb add legacy/helper allocN32Pixels, and convert gm to use it
This is an intermediate api, but might help us quickly get to a point where
no one is creating bitmaps in a 2-step process (setConfig + alloc).

BUG=skia:
R=halcanary@google.com

Review URL: https://codereview.chromium.org/140593005

git-svn-id: http://skia.googlecode.com/svn/trunk@13182 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-01-25 16:46:20 +00:00
senorblanco@chromium.org
8b66abb9bc Remove support for SK_CROP_RECT_IS_INT, now that it is no longer used in Blink or Chrome.
BUG=
R=reed@google.com, reed

Review URL: https://codereview.chromium.org/27521002

git-svn-id: http://skia.googlecode.com/svn/trunk@11812 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-16 15:46:00 +00:00
senorblanco@chromium.org
b295fb6ff3 Change SkImageFilter's cropRect from SkIRect to a CropRect struct, 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
2013-10-10 13:51:19 +00:00
robertphillips@google.com
1f2f338e23 Split SkDevice into SkBaseDevice and SkBitmapDevice
https://codereview.chromium.org/22978012/



git-svn-id: http://skia.googlecode.com/svn/trunk@10995 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-29 11:54:56 +00:00
senorblanco@chromium.org
fbaea53366 In image filters, apply the CTM and offset to the crop rect. This is necessary to compensate for both clipping applied by the compositor (communicated via the CTM) and for cropping applied in upstream image filters (communicated via the offset). This requires a few ugly conversions, since the crop rect is an SkIRect, and the ctm is an SkMatrix.
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
2013-08-27 21:37:01 +00:00
robertphillips@google.com
9b051a375b Revert r10830 (Split SkDevice out of SkRasterDevice) until we can get Chromium ready.
git-svn-id: http://skia.googlecode.com/svn/trunk@10835 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-20 20:06:40 +00:00
robertphillips@google.com
3055b70018 Split SkDevice out of SkBitmapDevice
https://codereview.chromium.org/22978012/



git-svn-id: http://skia.googlecode.com/svn/trunk@10830 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-20 17:49:04 +00:00
senorblanco@chromium.org
4e16bb2a32 Implement crop rect for lighting image filters. Changes for the CPU path 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
2013-07-26 00:10:07 +00:00