aboutsummaryrefslogtreecommitdiffhomepage
path: root/gm/lighting.cpp
Commit message (Collapse)AuthorAge
* stop using SkScalarMulGravatar Mike Reed2017-02-14
| | | | | | | | | 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>
* Replace a lot of 'static const' with 'constexpr' or 'const'.Gravatar mtklein2016-09-01
| | | | | | | | | | | | | | | | | | | | | | | '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
* Update LightingImageFilter to sk_spGravatar robertphillips2016-04-08
| | | | | | | | 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
* Make some GMs animateGravatar robertphillips2016-04-08
| | | | | | 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
* Update SkOffsetImageFilter to sk_spGravatar robertphillips2016-03-31
| | | | | | | | 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
* Revert of Update feSpotLight to match spec (patchset #2 id:20001 of ↵Gravatar caryclark2015-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update feSpotLight to match specGravatar ericrk2015-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Minor code cleanup (left over from prior CL)Gravatar robertphillips2015-09-03
| | | | | | 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
* Style Change: NULL->nullptrGravatar halcanary2015-08-27
| | | | | | DOCS_PREVIEW= https://skia.org/?cl=1316233002 Review URL: https://codereview.chromium.org/1316233002
* Style Change: SkNEW->new; SkDELETE->deleteGravatar halcanary2015-08-26
| | | | | | DOCS_PREVIEW= https://skia.org/?cl=1316123003 Review URL: https://codereview.chromium.org/1316123003
* Move LightingShader to effectsGravatar robertphillips2015-07-29
| | | | | | | | | | | 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
* make tests portable by using 565 compatible colorsGravatar caryclark2015-07-29
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1262703002
* rename portable_typeface_always to portable_typefaceGravatar caryclark2015-07-24
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1257773002
* make drawbitmaprect lighting lumafilter matrixconvolution srcmode gm portableGravatar caryclark2015-07-17
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1240843005
* Add new SkPoint3 classGravatar robertphillips2015-07-13
| | | | | | The existing Light filter and the upcoming Lighting Shader both need a Point3 class Review URL: https://codereview.chromium.org/1229693009
* Implement approx-match support in image filter saveLayer() offscreen.Gravatar senorblanco2015-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert of Implement approx-match support in image filter saveLayer() ↵Gravatar rmistry2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | offscreen. (patchset #31 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
* Implement approx-match support in image filter saveLayer() offscreen.Gravatar senorblanco2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert of Implement approx-match support in image filter saveLayer() ↵Gravatar rmistry2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | offscreen. (patchset #27 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
* Implement approx-match support in image filter saveLayer() offscreen.Gravatar senorblanco2015-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}Gravatar mtklein2015-03-25
| | | | | | | | | NOPRESUBMIT=true BUG=skia: DOCS_PREVIEW= https://skia.org/?cl=1037793002 Review URL: https://codereview.chromium.org/1037793002
* remove unused GM flagsGravatar mtklein2015-01-23
| | | | | | | | | | 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
* Fix up all the easy virtual ... SK_OVERRIDE cases.Gravatar mtklein2015-01-09
| | | | | | | | | | | | 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
* Cleanup: Another round of override fixes.Gravatar tfarina2014-12-20
| | | | | | | | BUG=skia:3075 TEST=ninja -C out/Debug TBR=mtklein@google.com Review URL: https://codereview.chromium.org/815883002
* Add standard fonts to all GMs.Gravatar Cary Clark2014-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Turn on quilt mode in DM.Gravatar commit-bot@chromium.org2014-04-30
| | | | | | | | | | | | | | | | | | - 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
* add peekPixels to SkCanvas and SkSurfaceGravatar commit-bot@chromium.org2014-02-13
| | | | | | | | | | | | | | 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
* Revert of add peekPixels to SkCanvas and SkSurface ↵Gravatar commit-bot@chromium.org2014-02-13
| | | | | | | | | | | | | | | | | | | | | | | | (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
* add peekPixels to SkCanvas and SkSurfaceGravatar mike@reedtribe.org2014-02-13
| | | | | | | | 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
* add legacy/helper allocN32Pixels, and convert gm to use itGravatar reed@google.com2014-01-25
| | | | | | | | | | | | 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
* Remove support for SK_CROP_RECT_IS_INT, now that it is no longer used in ↵Gravatar senorblanco@chromium.org2013-10-16
| | | | | | | | | | | 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
* Change SkImageFilter's cropRect from SkIRect to a CropRect struct, ↵Gravatar senorblanco@chromium.org2013-10-10
| | | | | | | | | | | | | | 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
* Split SkDevice into SkBaseDevice and SkBitmapDeviceGravatar robertphillips@google.com2013-08-29
| | | | | | | | https://codereview.chromium.org/22978012/ git-svn-id: http://skia.googlecode.com/svn/trunk@10995 2bbb7eff-a529-9590-31e7-b0007b416f81
* In image filters, apply the CTM and offset to the crop rect. This is ↵Gravatar senorblanco@chromium.org2013-08-27
| | | | | | | | | | | | | | 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
* Revert r10830 (Split SkDevice out of SkRasterDevice) until we can get ↵Gravatar robertphillips@google.com2013-08-20
| | | | | | Chromium ready. git-svn-id: http://skia.googlecode.com/svn/trunk@10835 2bbb7eff-a529-9590-31e7-b0007b416f81
* Split SkDevice out of SkBitmapDeviceGravatar robertphillips@google.com2013-08-20
| | | | | | | | https://codereview.chromium.org/22978012/ git-svn-id: http://skia.googlecode.com/svn/trunk@10830 2bbb7eff-a529-9590-31e7-b0007b416f81
* Implement crop rect for lighting image filters. Changes for the CPU path ↵Gravatar senorblanco@chromium.org2013-07-26
| | | | | | | | | | | | | | 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
* Changing imageFilter GM tests to use drawBitmap instead of drawSpriteGravatar junov@chromium.org2013-01-14
| | | | | | | The motivation is be able to test the filters with scaled SkPicture playback in isolation from the issues that surround usage of drawSprite Review URL: https://codereview.appspot.com/7060071 git-svn-id: http://skia.googlecode.com/svn/trunk@7152 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fix alpha computation for specular lighting filter (GPU path).Gravatar senorblanco@chromium.org2012-10-29
| | | | | | | | | | Change lighting GM background to show blending. NOTE: This will require new results for the lighting GM. Review URL: https://codereview.appspot.com/6812050 git-svn-id: http://skia.googlecode.com/svn/trunk@6181 2bbb7eff-a529-9590-31e7-b0007b416f81
* Result of running tools/sanitize_source_files.py (which was added in ↵Gravatar rmistry@google.com2012-08-23
| | | | | | | | | https://codereview.appspot.com/6465078/) This CL is part III of IV (I broke down the 1280 files into 4 CLs). Review URL: https://codereview.appspot.com/6475053 git-svn-id: http://skia.googlecode.com/svn/trunk@5264 2bbb7eff-a529-9590-31e7-b0007b416f81
* Raster implementation of diffuse and specular lighting filters. Externally,Gravatar senorblanco@chromium.org2012-06-22
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-24 18:49:45 +0000