aboutsummaryrefslogtreecommitdiffhomepage
path: root/include/effects
Commit message (Collapse)AuthorAge
...
* Revert of Matrix convolution bounds fix; affectsTransparentBlack fixes. ↵Gravatar senorblanco2015-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #4 id:60001 of https://codereview.chromium.org/1500923004/ ) Reason for revert: Introduced memory leak; pixel changes in Chrome. Original issue's description: > Matrix convolution bounds fix; affectsTransparentBlack fixes. > > Because the convolution kernel is (currently) applied in device space, > there's no way to know which object-space pixels will be touched. So > return false from canComputeFastBounds(). > > The results from the matrixconvolution GM were actually wrong, since > they were showing edge differences on the clip boundaries, where they > should really only show on crop boundaries. I added a crop to the GM > to keep the results the same (which are useful to test the different > convolution tile modes). > > While I was at it, SkImageFilter::affectsTransparentBlack() was > inapplicable on most things except color filters, and its use on > leaf nodes was confusing. So I removed it, and made > SkImageFilter::canComputeFastBounds() virtual instead. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/8705ec80518ef551994b82ca5ccaeb0241d6adec TBR=reed@google.com,reed@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1497083005
* Matrix convolution bounds fix; affectsTransparentBlack fixes.Gravatar senorblanco2015-12-04
| | | | | | | | | | | | | | | | | | | | | Because the convolution kernel is (currently) applied in device space, there's no way to know which object-space pixels will be touched. So return false from canComputeFastBounds(). The results from the matrixconvolution GM were actually wrong, since they were showing edge differences on the clip boundaries, where they should really only show on crop boundaries. I added a crop to the GM to keep the results the same (which are useful to test the different convolution tile modes). While I was at it, SkImageFilter::affectsTransparentBlack() was inapplicable on most things except color filters, and its use on leaf nodes was confusing. So I removed it, and made SkImageFilter::canComputeFastBounds() virtual instead. BUG=skia: Review URL: https://codereview.chromium.org/1500923004
* change more effects to only expose factoriesGravatar reed2015-10-12
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1395403002
* Revert "Revert of factories should return baseclass, allowing the impl to ↵Gravatar reed2015-10-06
| | | | | | | | | | | specialize (patchset #4 id:60001 of https://codereview.chromium.org/1390523005/ )" This reverts commit 95376a0dde3cdf414eb97a20cef3af19ed7e0151. BUG=skia: TBR= Review URL: https://codereview.chromium.org/1389083002
* Revert of factories should return baseclass, allowing the impl to specialize ↵Gravatar schenney2015-10-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #4 id:60001 of https://codereview.chromium.org/1390523005/ ) Reason for revert: Breaks Chrome with this link error: ../../third_party/skia/include/effects/SkMorphologyImageFilter.h:75: error: undefined reference to 'SkMorphologyImageFilter::SkMorphologyImageFilter(int, int, SkImageFilter*, SkImageFilter::CropRect const*)' ../../third_party/skia/include/effects/SkMorphologyImageFilter.h:104: error: undefined reference to 'SkMorphologyImageFilter::SkMorphologyImageFilter(int, int, SkImageFilter*, SkImageFilter::CropRect const*)' Presumably due to code in third_party/WebKit/Source/platform/graphics/filters/FEMorphology.cpp that contains: #include "SkMorphologyImageFilter.h" ... if (m_type == FEMORPHOLOGY_OPERATOR_DILATE) return adoptRef(SkDilateImageFilter::Create(radiusX, radiusY, input.get(), &rect)); return adoptRef(SkErodeImageFilter::Create(radiusX, radiusY, input.get(), &rect)); Original issue's description: > factories should return baseclass, allowing the impl to specialize > > waiting on https://codereview.chromium.org/1386163002/# to land > > BUG=skia:4424 > > Committed: https://skia.googlesource.com/skia/+/80a6dcaa1b757826ed7414f64b035d512d9ccbf8 TBR=senorblanco@google.com,robertphillips@google.com,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia:4424 Review URL: https://codereview.chromium.org/1389063002
* factories should return baseclass, allowing the impl to specializeGravatar reed2015-10-06
| | | | | | | | waiting on https://codereview.chromium.org/1386163002/# to land BUG=skia:4424 Review URL: https://codereview.chromium.org/1390523005
* Bye bye processor data manager.Gravatar bsalomon2015-10-06
| | | | Review URL: https://codereview.chromium.org/1388113002
* Move Mutexy things to private.Gravatar herb2015-09-29
| | | | | | | | | | There is no API change. TBR=reed@google.com BUG=skia: Review URL: https://codereview.chromium.org/1368333004
* Use child processors to implement compose color filter.Gravatar bsalomon2015-09-29
| | | | Review URL: https://codereview.chromium.org/1368423003
* Remove SkBitmapSourceGravatar fmalita2015-09-25
| | | | | | | | | To avoid breaking existing SKPs, add a deserialization stub which unflattens SkBitmapSource records to SkImageSources. R=reed@google.com,mtklein@google.com,robertphillips@google.com Review URL: https://codereview.chromium.org/1363913002
* Eliminate some clutter in SkFlattenableGravatar mdempsky2015-09-24
| | | | | | | | | | | | | | | | | | | | | The Registrar class is unnecessary, as SkFlattenable factory registration is now handled via initialization routines that can just call the Register function directly. Also, no need to lazily initialize gCount to 0, as initializing an int to a constant value does not require dynamic initialization. (C++ actually guarantees zero initialization of global ints anyway, but existing practice in Skia appears to favor the explicit "= 0"). Relatedly, this requires removing the unused/unimplemented SkLayerDrawLooper::MyRegistrar class. And removing that allows Clang to realize that SkLayerDrawLooper::fTopRec is unneeded too, so remove that too to squelch the compiler warning/error. This doesn't change any public API. TBR=reed@google.com Review URL: https://codereview.chromium.org/1361323002
* Create fragment processor for performing input color blend with child processorGravatar bsalomon2015-09-15
| | | | | | The new FP is used to implement SkXM::Mode color filters and SkXM::Mode image filters. Also, these now support all advanced SkXM::Mode xfermodes. Review URL: https://codereview.chromium.org/1334293003
* SkImageSourceGravatar fmalita2015-09-14
| | | | | | | | | | | | | Blink is migrating away from SkBitmaps, so we need an SkImage-based SkImageFilter source. This is pretty much a 1-1 equivalent of SkBitmapSource. To avoid duplication, relocate the SkImage deserialization logic from SkPictureData to SkReadBuffer. R=reed@google.com,robertphillips@google.com,senorblanco@chromium.org Review URL: https://codereview.chromium.org/1343703005
* Change SkShader;asFragmentProcessor signature to no longer take skpaint\grcolor*Gravatar bsalomon2015-08-28
| | | | | | Committed: https://skia.googlesource.com/skia/+/ecfdc251be71f3d634e76afdd6375bf55fc061aa Review URL: https://codereview.chromium.org/1316513002
* Revert of Change SkShader;asFragmentProcessor signature to no longer take ↵Gravatar rmistry2015-08-28
| | | | | | | | | | | | | | | | | | | | | | | | skpaint\grcolor* (patchset #8 id:140001 of https://codereview.chromium.org/1316513002/ ) Reason for revert: Primary suspect in failing DEPS rolls: * https://codereview.chromium.org/1315753006 * https://codereview.chromium.org/1308323006 * https://codereview.chromium.org/1320903004 Primary suspect because the failing win bots did not fail in https://codereview.chromium.org/1315753005 Original issue's description: > Change SkShader;asFragmentProcessor signature to no longer take skpaint\grcolor* > > Committed: https://skia.googlesource.com/skia/+/ecfdc251be71f3d634e76afdd6375bf55fc061aa TBR=joshualitt@google.com,wangyix@google.com,robertphillips@google.com,bsalomon@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1313573005
* Change SkShader;asFragmentProcessor signature to no longer take skpaint\grcolor*Gravatar bsalomon2015-08-28
| | | | Review URL: https://codereview.chromium.org/1316513002
* Style Change: SkNEW->new; SkDELETE->deleteGravatar halcanary2015-08-26
| | | | | | DOCS_PREVIEW= https://skia.org/?cl=1316123003 Review URL: https://codereview.chromium.org/1316123003
* Reland of Implement canComputeFastBounds() for image filters. (patchset #1 ↵Gravatar senorblanco2015-08-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:1 of https://codereview.chromium.org/1300403003/ ) Reason for revert: The Mac compile issue was fixed here: https://chromium.googlesource.com/chromium/src/+/fdd331a42ae0b9a6909a121020735161ab61c6e5 Original issue's description: > Revert of Implement canComputeFastBounds() for image filters. (patchset #8 id:130001 of https://codereview.chromium.org/1296943002/ ) > > 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/+/915881fe743f9a789037695f543bc6ea189cd0cb > > TBR=reed@google.com,senorblanco@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=4212 > > Committed: https://skia.googlesource.com/skia/+/12d8472d31ea5edb636d7d5214db253570115c40 TBR=reed@google.com,herb@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=4212 Review URL: https://codereview.chromium.org/1301823005
* Revert of Implement canComputeFastBounds() for image filters. (patchset #8 ↵Gravatar herb2015-08-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:130001 of https://codereview.chromium.org/1296943002/ ) 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/+/915881fe743f9a789037695f543bc6ea189cd0cb TBR=reed@google.com,senorblanco@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=4212 Review URL: https://codereview.chromium.org/1300403003
* Implement canComputeFastBounds() for image filters.Gravatar senorblanco2015-08-20
| | | | | | | | | | | | | | | | | | | | | | 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
* Update SkLightingShader to support rotationGravatar robertphillips2015-08-20
| | | | | | | | | | | | | 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) Committed: https://skia.googlesource.com/skia/+/45b59ed6e4e231814dbdb9f707b3d2a7ee50de84 Review URL: https://codereview.chromium.org/1291783003
* SkColorCubeFilter: require alpha == 0xFF.Gravatar mtklein2015-08-19
| | | | | | | | This is about a 12% improvement on my desktop, from 134 to 118ms on our bench. BUG=skia: Review URL: https://codereview.chromium.org/1295873004
* Revert "Update SkLightingShader to support rotation"Gravatar robertphillips2015-08-19
| | | | | | | | This reverts commit 45b59ed6e4e231814dbdb9f707b3d2a7ee50de84. TBR=herb@google.com Review URL: https://codereview.chromium.org/1304673002
* Update SkLightingShader to support rotationGravatar robertphillips2015-08-19
| | | | | | | | | | | 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
* Remove SK_LEGACY_SKPOINT3_CTORS flagGravatar robertphillips2015-08-06
| | | | | | Cannot land before Blink https://codereview.chromium.org/1274673002/ (Remove reliance on legacy Skia SkPoint3 ctors in FELighting.cpp) Review URL: https://codereview.chromium.org/1269383003
* Address some SkLightingShader TODOsGravatar robertphillips2015-07-31
| | | | | | | | This CL: switches the light colors to be 3 scalars (SkColor3f) adds some dox Review URL: https://codereview.chromium.org/1265983003
* 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
* rename GrShaderDataManager -> GrProcessorDataManagerGravatar joshualitt2015-07-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1228683002
* Thread GrShaderDataManager through Image filtersGravatar joshualitt2015-07-08
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1229613002
* More threading of GrShaderDataManagerGravatar joshualitt2015-07-08
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1213613016
* Initial CL to create dummy GrShaderDataManager and thread it throughGravatar joshualitt2015-07-08
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1225673007
* style nit cleanups. e.g. remove 'virtual' on override declarationsGravatar robertphillips2015-07-07
| | | | Review URL: https://codereview.chromium.org/1216433005
* remove SkInstCntGravatar mtklein2015-06-26
| | | | | | | | | | | | | | It's been outclassed by Valgrind and leak sanitizer, and it seems to be causing problems for external folks building Skia. I'm not sure why our own builds seem unaffected. Latest thread: https://groups.google.com/forum/#!topic/skia-discuss/oj9FsQwwSF0 BUG=skia: Review URL: https://codereview.chromium.org/1217573002
* remove SK_SUPPORT_LEGACY_FILTERLEVEL_ENUMGravatar reed2015-06-23
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1205803002
* Clean up usage of SkSurfacePropsGravatar robertphillips2015-06-22
| | | | | | | | | | | | 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
* Fix dst bound reported by SkTileImageFilterGravatar robertphillips2015-06-16
| | | | | | | | | | | | | | | | | | | | | | | | 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/+/0be685755f942baea26c66a87226b569fc17e960 Review URL: https://codereview.chromium.org/1152553006
* retro add copyrightGravatar reed2015-06-11
| | | | | | | | BUG=skia: NOTRY=True TBR= Review URL: https://codereview.chromium.org/1183463002
* Add bigtileimagefilter GM & improvements to toStringGravatar robertphillips2015-06-08
| | | | | | | | This is all the ancillary code from https://codereview.chromium.org/1152553006/ (Fix dst bound reported by SkTileImageFilter). TBR=reed@google.com, senorblanco@google.com Review URL: https://codereview.chromium.org/1169713003
* delete (unused) TransparentShaderGravatar reed2015-06-05
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1153193014
* Revert of Fix dst bound reported by SkTileImageFilter (patchset #3 id:40001 ↵Gravatar robertphillips2015-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of https://codereview.chromium.org/1152553006/) 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/+/0be685755f942baea26c66a87226b569fc17e960 TBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=493783 Review URL: https://codereview.chromium.org/1156583004
* Fix dst bound reported by SkTileImageFilterGravatar robertphillips2015-06-04
| | | | | | | | | | | | | | | | | | | | | | 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
* Revert of Fix dst bound reported by SkTileImageFilter (patchset #3 id:40001 ↵Gravatar robertphillips2015-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of 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/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e TBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=493783 Review URL: https://codereview.chromium.org/1143083006
* Fix dst bound reported by SkTileImageFilterGravatar robertphillips2015-06-02
| | | | | | | | | | | | | | | | | | | | 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
* remove redundant/deprecated TwoPointRadial gradiet -- use TwoPointConicalGravatar reed2015-05-04
| | | | | | | | This CL derived from https://codereview.chromium.org/1114243005/ BUG=skia: Review URL: https://codereview.chromium.org/1117423003
* Use GLSLCaps for creating processor keys and GLSL-specific programsGravatar jvanverth2015-04-28
| | | | | | | | | 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
* Add GM to repro crbug.com/472795Gravatar robertphillips2015-04-09
| | | | | | | | 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
* Refactor Sk2x<T> + Sk4x<T> into SkNf<N,T> and SkNi<N,T>Gravatar mtklein2015-03-30
| | | | | | | | | | | | | | | | | | | | | 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
* 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
* Revert of Revert of remove colorfilter native-565 support. complicating w/ ↵Gravatar reed2015-03-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | no real value. (patchset #1 id:1 of https://codereview.chromium.org/1022673007/) Reason for revert: fix for chrome has landed... Original issue's description: > Revert of remove colorfilter native-565 support. complicating w/ no real value. (patchset #2 id:20001 of https://codereview.chromium.org/1015533011/) > > Reason for revert: > skia/ext/benchmarking_canvas.cc references HasFilter16 :( > > Original issue's description: > > remove colorfilter native-565 support. complicating w/ no real value. > > > > BUG=skia: > > TBR= > > > > Committed: https://skia.googlesource.com/skia/+/2151353d161fe389cdc0db62cfe1932c7680f710 > > TBR=reed@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/92b47c49016749249ff8521e424c4373b4a74241 TBR=reed@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1016103004
* Revert of remove colorfilter native-565 support. complicating w/ no real ↵Gravatar reed2015-03-24
| | | | | | | | | | | | | | | | | | | | | | | value. (patchset #2 id:20001 of https://codereview.chromium.org/1015533011/) Reason for revert: skia/ext/benchmarking_canvas.cc references HasFilter16 :( Original issue's description: > remove colorfilter native-565 support. complicating w/ no real value. > > BUG=skia: > TBR= > > Committed: https://skia.googlesource.com/skia/+/2151353d161fe389cdc0db62cfe1932c7680f710 TBR=reed@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1022673007
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 05:33:38 +0000