aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core
Commit message (Collapse)AuthorAge
* Add evenly spaced stops and unify gradient contextsGravatar Herb Derby2017-05-15
| | | | | | | Change-Id: I17ac13b9d1ea6765e2c1a2b53aa6975eab408856 Reviewed-on: https://skia-review.googlesource.com/16713 Commit-Queue: Herb Derby <herb@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* composeshader stagesGravatar Mike Reed2017-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | needed to add two helper stages for composeshader load_rgba, store_rgba These just read/write the r,g,b,a registers to context memory, making no promise as to how the memory is formatted (e.g. interleaved -vs- planar). Note that we have similar existing stages, but they did not seem to suit: constant_color This guy loads 4 floats from memory, and splats them into registers. I need to load 4 entire registers. load_f32, store_f32 These offset where they read/write based on the 'x' register, plus they guarantee that the memory will be interleaved ala SkPM4f. Bug: skia: Change-Id: Iaa81f950660b837bdb34416ab3e342d56a92239b Reviewed-on: https://skia-review.googlesource.com/16716 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* move impl for drawvertices into separate fileGravatar Mike Reed2017-05-15
| | | | | | | | | | | expect to refactor the impl, so this just makes that easier (plus SkDraw.cpp was just too big) Bug: skia: Change-Id: I22c07d37429195363d9a76e56a1dca915f9c2d57 Reviewed-on: https://skia-review.googlesource.com/16863 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org>
* Allow numerical color spaces with legacy renderingGravatar Matt Sarett2017-05-15
| | | | | | | | Bug: 720083 Change-Id: Ibd4dbf6ee95ac14857e8280a441f81976710e5e8 Reviewed-on: https://skia-review.googlesource.com/16700 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
* Sort all user-supplied rects before computeFastBoundsGravatar Brian Osman2017-05-13
| | | | | | | | | | | | | | | | https://codereview.chromium.org/908353002 fixed drawRect 2+ years ago, but drawOval and drawArc were still susceptible. This version ensures that all rects are sorted before we do the bounds check. Added a new makeSorted helper to simplify the code, and an assert to catch any future oversight. All other drawing functions compute their bounds rect in some way that already ensures it is sorted. Bug: skia: Change-Id: I8926b2dbe9d496d0876f1ac5313bd058ae4568b7 Reviewed-on: https://skia-review.googlesource.com/16702 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
* implement 4f for composeshaderGravatar Mike Reed2017-05-12
| | | | | | | | Bug: skia: Change-Id: I7ad0077345f7589528c89cd84d252539a1df6614 Reviewed-on: https://skia-review.googlesource.com/16703 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* Add new SkImageGenerator::getPixels() API, deprecate the oldGravatar Matt Sarett2017-05-12
| | | | | | | | | | | | This is fairly aggressive in that it will break any client that is currently using SkImageGenerator with kIndex8. I'm guessing that we don't have any clients doing that. Bug: skia:6620 Change-Id: Ifd16f5232bb3a9f759c225315c57492d917ed9ca Reviewed-on: https://skia-review.googlesource.com/16601 Commit-Queue: Matt Sarett <msarett@google.com> Reviewed-by: Mike Reed <reed@google.com>
* fold matrices together for tricolorGravatar Mike Reed2017-05-12
| | | | | | | | Bug: skia: Change-Id: Ic4ef679c6b5514f0fc7f895d71b5feeb812da53e Reviewed-on: https://skia-review.googlesource.com/16606 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* Cleanup SkImageGenerator, add missing fns to GrBackendTextureImageGeneratorGravatar Brian Osman2017-05-12
| | | | | | | | | | | | No "real" API changes. TBR=reed@google.com Bug: skia: Change-Id: I08c29f76806388394938f204f2a50b2fd6ea8942 Reviewed-on: https://skia-review.googlesource.com/16662 Reviewed-by: Brian Osman <brianosman@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
* Pass alphaType to append_gamut_transform() to inform the clampGravatar Matt Sarett2017-05-12
| | | | | | | | | BUG=skia: Change-Id: I1a8aef36043d4091bffae95b0275fa7fa8a35c97 Reviewed-on: https://skia-review.googlesource.com/9441 Commit-Queue: Matt Sarett <msarett@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* refactor gradient stage namesGravatar Mike Klein2017-05-12
| | | | | | | | | | | | | | | | | | | | | | This is just a name refactor and I'm happy to delay it until we're done with the current wave of gradient CLs. The main ideas: - we use the "linear_gradient" stages for all gradients, so cut the "linear" and just call them "gradient"; - remind ourselves that the 2-stop stage requires even spacing, i.e. stops at 0 and 1. This name should harmonize with Herb's new general evenly spaced gradient stage, currently "evenly_spaced_linear_gradient", and after it lands and I rebase, "evenly_spaced_gradient" - remind ourselves which polar coordinate xy_to_polar_unit returns, the angle. Change-Id: I0fd0c8bd4c1ead7d2d0fff45a199d318b71f34ac Reviewed-on: https://skia-review.googlesource.com/16500 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Mike Reed <reed@google.com>
* Revert "Evenly space gradient stage."Gravatar Mike Klein2017-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 892501d09bc8608704362235c73a59bb23a386b3. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=721682 :( Original change's description: > Evenly space gradient stage. > > This seems like an experiment at this point because I don't know how to do > this kind of thing on arm. > > > Numbers from Skylake... > Before: > ./out/Release/nanobench --config srgb \ > --match gradient_linear_clamp_3color gradient_linear_clamp_hicolor -q 19:48:13 > Timer overhead: 36.7ns > ! -> high variance, ? -> moderate variance > micros bench > 439.92 ? gradient_linear_clamp_3color srgb > 2697.60 gradient_linear_clamp_hicolor srgb > 437.28 gradient_linear_clamp_3color_4f srgb > 2700.50 gradient_linear_clamp_hicolor_4f srgb > > > After: > micros bench > 382.35 gradient_linear_clamp_3color srgb > 593.49 gradient_linear_clamp_hicolor srgb > 382.36 gradient_linear_clamp_3color_4f srgb > 565.60 gradient_linear_clamp_hicolor_4f srgb > > > Numbers on my Mac Trashcan are about even; there is no > speedup or slowdown between master and this change. > > Change-Id: I04402452e23c0888512362fd1d6d5436cea61719 > Reviewed-on: https://skia-review.googlesource.com/15960 > Commit-Queue: Herb Derby <herb@google.com> > Reviewed-by: Mike Klein <mtklein@chromium.org> > TBR=mtklein@chromium.org,mtklein@google.com,herb@google.com,fmalita@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: Ic6a064c66686b6f238ca1417ba1abd9ce25de1b4 Reviewed-on: https://skia-review.googlesource.com/16660 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Evenly space gradient stage.Gravatar herb2017-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This seems like an experiment at this point because I don't know how to do this kind of thing on arm. Numbers from Skylake... Before: ./out/Release/nanobench --config srgb \ --match gradient_linear_clamp_3color gradient_linear_clamp_hicolor -q 19:48:13 Timer overhead: 36.7ns ! -> high variance, ? -> moderate variance micros bench 439.92 ? gradient_linear_clamp_3color srgb 2697.60 gradient_linear_clamp_hicolor srgb 437.28 gradient_linear_clamp_3color_4f srgb 2700.50 gradient_linear_clamp_hicolor_4f srgb After: micros bench 382.35 gradient_linear_clamp_3color srgb 593.49 gradient_linear_clamp_hicolor srgb 382.36 gradient_linear_clamp_3color_4f srgb 565.60 gradient_linear_clamp_hicolor_4f srgb Numbers on my Mac Trashcan are about even; there is no speedup or slowdown between master and this change. Change-Id: I04402452e23c0888512362fd1d6d5436cea61719 Reviewed-on: https://skia-review.googlesource.com/15960 Commit-Queue: Herb Derby <herb@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* Add a way to force raster pipeline blitter.Gravatar Mike Klein2017-05-11
| | | | | | | | | | | | And add some Test/Perf bots to try it out! CQ_INCLUDE_TRYBOTS=skia.primary:Perf-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Release-SK_FORCE_RASTER_PIPELINE_BLITTER Change-Id: I56ea2285f9fec2e468fae89673a545a717ab0f49 Reviewed-on: https://skia-review.googlesource.com/16423 Reviewed-by: Eric Boren <borenet@google.com> Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* A8 fast path for raster clip masksGravatar Florin Malita2017-05-11
| | | | | | | | | | | | | | | | | | | When the clip mask is already A8, we don't need to convert explicitly. Before: 792.72 clipmask_a8 8888 After: 560.06 clipmask_a8 8888 BUG=skia:6005 Change-Id: I9a319df9a82edfc9b412787a36f037bbe82c2825 Reviewed-on: https://skia-review.googlesource.com/16420 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Remove comments referencing locked pixelsGravatar Leon Scroggins III2017-05-10
| | | | | | | | | | | | | Pixels no longer need to be locked. TBR=reed@google.com Bug: skia: 6481 Change-Id: I4b49f710add9134205d1520755b44bee308bd502 Reviewed-on: https://skia-review.googlesource.com/16113 Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Make SkCreateRasterPipelineBlitter() not fail.Gravatar Mike Klein2017-05-10
| | | | | | | | | | | | | | Mostly this is about extending the fallback in SkShader::appendStages() to cover more cases, and making sure subclasses call appendStages() so they can get the fallback, not onAppendStages() directly. We still need to watch for SkShader::makeContext() failing in the fallback itself, so sadly SkShader::appendStages() may still fail. Change-Id: I2314b234a24bdcecac401a385ce050d7fdf0a83e Reviewed-on: https://skia-review.googlesource.com/16369 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* use SkColorSpaceXformer in SkShader appendStages() fallbackGravatar Mike Klein2017-05-10
| | | | | | | | | | | | | We've been transforming the gamut after running the legacy shader, but now that we have SkColorSpaceXformer, we can transform the legacy shader into the dst color space instead. This should be both more correct and faster. Change-Id: If017048874e6cce46837d3ecbd88dfde503fd03a Reviewed-on: https://skia-review.googlesource.com/16373 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* clean up SkShader friendsGravatar Mike Klein2017-05-10
| | | | | | | | | | | | | | | Many SkShader subclasses are only friends to use makeColorSpace(). Our usual solution to this is to add a method on SkColorSpaceXformer that calls makeColorSpace() for us, so that only SkColorSpaceXformer needs to be a friend. Just a refactor. No image diffs. Change-Id: Icf952b739edf45f2fb8c0c35e353ef2866f4c5cc Reviewed-on: https://skia-review.googlesource.com/16370 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* add flag to hide deprecated clipopsGravatar Mike Reed2017-05-10
| | | | | | | | | | | | needs this to land first https://codereview.chromium.org/2877493002/# Bug: skia:3191 Change-Id: Iff5271064877c4e96353d3564464f513eaad0bb5 Reviewed-on: https://skia-review.googlesource.com/16365 Reviewed-by: Brian Salomon <bsalomon@google.com> Reviewed-by: Hal Canary <halcanary@google.com> Commit-Queue: Mike Reed <reed@google.com>
* void SkColorFilter::onAppendStages(...)Gravatar Mike Klein2017-05-09
| | | | | | | | | | | SkColorFilter::onAppendStages() can't actually fail today. Let's enforce that. This means the fallback is now used only for color filters that have not implemented onAppendStages(). Change-Id: Ica3939685694f6186727766b54914b9ba05ca68c Reviewed-on: https://skia-review.googlesource.com/16231 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* fix 565Gravatar Mike Klein2017-05-09
| | | | | | | | | Change-Id: Ibde5242dc4f66b720cb8be1e2d771ba88b12b496 Reviewed-on: https://skia-review.googlesource.com/16241 Commit-Queue: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Matt Sarett <msarett@google.com> Reviewed-by: Matt Sarett <msarett@google.com>
* move set-text-matrix into privateGravatar Mike Reed2017-05-09
| | | | | | | | | | Had no external callers, and was poorly named. Bug: skia: Change-Id: I5bed6853e9aa3b31fa106a436a73297bf55f0503 Reviewed-on: https://skia-review.googlesource.com/16155 Reviewed-by: Cary Clark <caryclark@google.com> Commit-Queue: Mike Reed <reed@google.com>
* make append_gamut_tranform() never failGravatar Mike Klein2017-05-09
| | | | | | | | | | | | | | The only way it could ostensibly fail is if we get non-XYZ color spaces, which should just not happen. Assert that doesn't happen and safely do nothing instead of failing. This is one of the leaf nodes to getting SkCreateRasterPipelineBlitter to never fail. Next come SkColorFilter:: and SkShader::appendStages(). Change-Id: I5c7a8c63d0a9837e2e55208e1674796d86f45307 Reviewed-on: https://skia-review.googlesource.com/16002 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Matt Sarett <msarett@google.com>
* Make SkColorFilter::appendStages() not fail.Gravatar Mike Klein2017-05-09
| | | | | | | | | | | | | | | | | | This makes SkColorFilter::appendStages() first try onAppendStages(), and if it's unimplemented or fails, fall back to filterSpan4f(). This also makes onAppendStages() private to try to ensure that appendStages() is now its only caller, ensuring everyone goes through this fallback path. The fallback uses the color filter transformed into the dst colorspace using our new SkColorSpaceXformer... that seem ok Matt? Change-Id: I4751a6859596fa4f7e844e69ef0d986f005b52c7 Reviewed-on: https://skia-review.googlesource.com/16031 Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Convert color to dst (once) in color shadersGravatar Matt Sarett2017-05-09
| | | | | | | | | BUG=skia: Change-Id: Ideba16972b82fc26766349c808ae406e5ea23163 Reviewed-on: https://skia-review.googlesource.com/9418 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Matt Sarett <msarett@google.com>
* Forward getGrContext in color space xform canvasGravatar Brian Osman2017-05-09
| | | | | | | | Bug: chromium:719664 Change-Id: I7477c1eb0479d5305233dc6a643280d88029bd17 Reviewed-on: https://skia-review.googlesource.com/15888 Reviewed-by: Brian Salomon <bsalomon@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
* remove (possibly slow) call to refEncoded in getDeferredTextureImageDataGravatar Mike Reed2017-05-09
| | | | | | | | | | | | | | | - explicitly reject already-texture-backed and picture-backed Needed to add a virtual to image_base and generator to distinguish generators that can (or cannot) natively "generate" on the gpu (e.g. pictures) Bug: 646089 Change-Id: I3aea22f89b31009ecbb3bd50d88512e6532f0a0f Change-Id: I3aea22f89b31009ecbb3bd50d88512e6532f0a0f Reviewed-on: https://skia-review.googlesource.com/15765 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
* Add radial gradient stage.Gravatar Herb Derby2017-05-09
| | | | | | | Change-Id: Ie1f9640f5149f21bd8b3b864ff8b176232e1b0a9 Reviewed-on: https://skia-review.googlesource.com/15461 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Herb Derby <herb@google.com>
* "can we?" -> "do we want to?" for SkRasterPipelineBlitterGravatar Mike Klein2017-05-08
| | | | | | | | | | | | | | | | | There has been a supported() function in SkRasterPipelineBlitter.cpp for a long time that's becoming increasingly misnamed. That blitter ought to be able to handle all destination formats. This CL moves that logic outside to the creator of the blitter, changing it from "can we handle this format?" to "do we want to use this blitter for this format?". In other CLs I'm working to make creating a pipeline blitter never fail. Change-Id: Ie59fb8ec6e63d215d1baef439e464e8f0ab3ae4d Reviewed-on: https://skia-review.googlesource.com/15842 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* SkAdvancedTypefaceMetrics: pack fields betterGravatar Hal Canary2017-05-08
| | | | | | | | | | 64-bit pointers: 88 -> 80 bytes 32-bit pointers: 68 -> 64 bytes Change-Id: I2d6e186d15ad84a3b23bf8f6c816eaf482c3bdd5 Reviewed-on: https://skia-review.googlesource.com/15878 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* Minimize computeTotalInverse()'s inputsGravatar Florin Malita2017-05-08
| | | | | | | | | The helper doesn't need a full context rec - it only looks at the CTM and external local matrix. Pass these explicitly instead. Change-Id: I6a5884f65cd383c2df0e8d83c9086789bd96f345 Reviewed-on: https://skia-review.googlesource.com/15870 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Re-land of "eliminated GrGLSLExpr".Gravatar Ethan Nicholas2017-05-08
| | | | | | | | | | | This change is exactly the same as the last time it was landed; I believe the underlying optimizer bug that was causing this to cause problems has been fixed by a prior CL. Bug: skia: Change-Id: I5436422f094ea758caa3cd69e9338db31b1f93fa Reviewed-on: https://skia-review.googlesource.com/15768 Reviewed-by: Ethan Nicholas <ethannicholas@google.com> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
* SkImage::isValidGravatar Brian Osman2017-05-08
| | | | | | | | | | | | Lets clients know if an image is drawable to a particular GrContext (or to CPU). Checks for abandoned GrContexts beneath GPU backed images, as well as context mis-match. Bug: skia: Change-Id: Ibe88c7ce8091f965c14f6023a3597be4b70c3f99 Reviewed-on: https://skia-review.googlesource.com/15801 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
* jumper, finish blend modesGravatar Mike Klein2017-05-08
| | | | | | | | | | | | | | I've decided to ignore our existing CPU implementations and start from scratch, mostly referencing the GL ES 3.2 spec and w3 spec. This implementation ought to look a lot like the reference implementation I've written in gm/hsl.cpp, with the addition of handling alpha: unpremul, blend, re-premul with a simple SrcOver alpha. Change-Id: I38cf6be2dc66a6f46d7b18b91847f6933d2fab62 Reviewed-on: https://skia-review.googlesource.com/15316 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* remove old 565 destination optsGravatar Mike Klein2017-05-06
| | | | | | | | | | This is not an important format, and the code is dead or close to it. The code is an occasional maintenance burden so I'd like it gone. Change-Id: I4ad921533abf3211e6a81e6e475b848795eea060 Reviewed-on: https://skia-review.googlesource.com/15600 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* impl 4f version for tricolor shaderGravatar Mike Reed2017-05-06
| | | | | | | | Bug: skia: Change-Id: I43f456aa115ce71a5d1acd9bc94984248a88319a Reviewed-on: https://skia-review.googlesource.com/15540 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Reed <reed@google.com>
* composecolorfilter can now append stagesGravatar Mike Reed2017-05-05
| | | | | | | | Bug: skia: Change-Id: I46b54e5fd09de16b467142a5501b226273182d52 Reviewed-on: https://skia-review.googlesource.com/15615 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* SkTypeface: remove old virtual onGetAdvancedMetrics, since ↵Gravatar Hal Canary2017-05-05
| | | | | | | | | https://crrev.com/2860293003 Change-Id: Iad30b03fc8b34bdea2fe902f83a0dd979c16f1a7 Reviewed-on: https://skia-review.googlesource.com/15633 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* speed-up 4f version of modecolorfilter and modulateGravatar Mike Reed2017-05-05
| | | | | | | | | | | | | ~20% faster 1. Don't call color4f::premul on every invocation 2. Inline modulate as its own special case (used by shadows) Bug: skia: Change-Id: I49ca565f589b9a7caac88e95468da7f8c395804a Reviewed-on: https://skia-review.googlesource.com/15613 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* Avoid interpolating color lut with less than 2 pointsGravatar Matt Sarett2017-05-05
| | | | | | | | Bug: 717935 Change-Id: Ibf15b815891eef5a0239bc408bcbfe7c8b1507c5 Reviewed-on: https://skia-review.googlesource.com/15301 Commit-Queue: Matt Sarett <msarett@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* Revert "Revert "SkTypeface::getAdvancedMetrics(): cleanup""Gravatar Hal Canary2017-05-05
| | | | | | | | | | | | | | | | | | | This reverts commit 59ad782b2b05b07aa6eb961aa4d62e934093cbd1. - SkAdvancedTypefaceMetrics is a struct not a class - SkTypeface::PerGlyphInfo is gone - s/getAdvancedTypefaceMetrics/getAdvancedMetrics/g - s/onGetAdvancedTypefaceMetrics/onGetAdvancedMetrics/g - [on]getAdvancedMetrics now return unique_ptr rather than bare ptr. - [on]getAdvancedMetrics no longer has parameters. (Only caller always used same arguments.) - SkAdvancedTypefaceMetrics uses C++11 in-class member initializers. - SkAdvancedTypefaceMetrics no longer inherits from SkRefCnt Change-Id: I91b56e60f7d9de7d46c426c6bd34ce124e0cf00e Reviewed-on: https://skia-review.googlesource.com/15360 Reviewed-by: Hal Canary <halcanary@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* Revert "SkTypeface::getAdvancedMetrics(): cleanup"Gravatar Hal Canary2017-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit cef018896e5cad8eb46a536b60cdf79ebe2b0191. Reason for revert: broke chromium roll (windows). Original change's description: > SkTypeface::getAdvancedMetrics(): cleanup > > - SkAdvancedTypefaceMetrics is a struct not a class > - SkTypeface::PerGlyphInfo is gone > - s/getAdvancedTypefaceMetrics/getAdvancedMetrics/g > - s/onGetAdvancedTypefaceMetrics/onGetAdvancedMetrics/g > - [on]getAdvancedMetrics now return unique_ptr rather than bare ptr. > - [on]getAdvancedMetrics no longer has parameters. (Only caller always > used same arguments.) > - SkAdvancedTypefaceMetrics uses C++11 in-class member initializers. > - SkAdvancedTypefaceMetrics no longer inherits from SkRefCnt > > Change-Id: I37571ebcc383ba9eb21bc20c60c734e3ca317582 > Reviewed-on: https://skia-review.googlesource.com/15311 > Reviewed-by: Ben Wagner <bungeman@google.com> > Commit-Queue: Hal Canary <halcanary@google.com> > TBR=halcanary@google.com,bungeman@google.com,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I84c7d53df566aaf83427e3368edaa02b7b5a9cb8 Reviewed-on: https://skia-review.googlesource.com/15319 Reviewed-by: Hal Canary <halcanary@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* SkTypeface::getAdvancedMetrics(): cleanupGravatar Hal Canary2017-05-04
| | | | | | | | | | | | | | | | | - SkAdvancedTypefaceMetrics is a struct not a class - SkTypeface::PerGlyphInfo is gone - s/getAdvancedTypefaceMetrics/getAdvancedMetrics/g - s/onGetAdvancedTypefaceMetrics/onGetAdvancedMetrics/g - [on]getAdvancedMetrics now return unique_ptr rather than bare ptr. - [on]getAdvancedMetrics no longer has parameters. (Only caller always used same arguments.) - SkAdvancedTypefaceMetrics uses C++11 in-class member initializers. - SkAdvancedTypefaceMetrics no longer inherits from SkRefCnt Change-Id: I37571ebcc383ba9eb21bc20c60c734e3ca317582 Reviewed-on: https://skia-review.googlesource.com/15311 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* force all colorfilters to implement 4fGravatar Mike Reed2017-05-04
| | | | | | | | | | | high-contrast gms differ at most by 1 bit Bug: skia: Change-Id: I1308bd105020ea3cd5a30fd3dd322ed134fb5ed5 Reviewed-on: https://skia-review.googlesource.com/15249 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org>
* move dither after the transfer functionGravatar Mike Klein2017-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no single dither rate that we can use in linear space if we're using a non-linear transfer function... if it's too high (like today) we'll dither too much around zero (e.g. 0 -> 5), and if it's too low we won't dither near one. We were thinking it'd be a good idea to move the dither later in the pipeline anyway. This has to be the right spot! Now that we're moving dither from operating in linear space to operating in bit-space (after transfer function, aware of bit-depth of destination) we have to start clamping [0,1] instead of [0,a]... But, I think I've rewritten things to make sure we don't need to clamp at all. The main idea is to make sure 0-dither and 1+dither round to 0 and 1 respectively. We can do this by making the dither span exclusive, switching from [-0.5,+0.5] to (-0.5,+0.5). In practice I'm doing that as [-0.4921875,+0.4921875], a maximum dither of 63/128 of a bit. Similarly, I don't think it makes sense to fold in the multiply by alpha anymore if we're after the transfer function. Change-Id: I55857bca80377c639fcdd29acc9b362931dd9d12 Reviewed-on: https://skia-review.googlesource.com/15254 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Revert "Revert "Revert "eliminated GrGLSLExpr"""Gravatar Ethan Nicholas2017-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 796001c82eca5651bc6a221204f6186918781daf. Reason for revert: looks to be causing problems in Chrome (https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Linux_Trusty__dbg_/1553/layout-test-results/results.html) Original change's description: > Revert "Revert "eliminated GrGLSLExpr"" > > This reverts commit 5e550ab57e0204bfadd2cb69c47d2a85e38d6a4c. > > Bug: skia: > Change-Id: I4705e47dbd209aa8f43db3d28c856bd3aa9e49ab > Reviewed-on: https://skia-review.googlesource.com/15187 > Reviewed-by: Ethan Nicholas <ethannicholas@google.com> > Commit-Queue: Ethan Nicholas <ethannicholas@google.com> > TBR=ethannicholas@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I6455a4f16b2dc0d6d1265541f7117e0cfb8dd91c Reviewed-on: https://skia-review.googlesource.com/15309 Reviewed-by: Ethan Nicholas <ethannicholas@google.com> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
* Finish removal of SkImageInfo from SkPixelRefGravatar Matt Sarett2017-05-04
| | | | | | | | | | All of the clients are updated. We don't need this anymore. Bug: skia:6535 Change-Id: I1399a08b7dda8f29c4f4016a1de50ee8310c1fef Reviewed-on: https://skia-review.googlesource.com/15106 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
* Revert "treat SkPMColor as sRGB in SkPM4f::FromPMColor()"Gravatar Mike Klein2017-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a4f3e14d896708376aa50b2a8804796e6e1ee644. Reason for revert: affecting 565 in ways I didn't expect Original change's description: > treat SkPMColor as sRGB in SkPM4f::FromPMColor() > > We made the wrong call in SkPM4f::FromPMColor(). SkPM4f::FromPMColor() > is only used by the color correct drawing pipeline, not legacy. That > means it makes a lot more sense to treat SkPMColors as premul sRGB than > premul linear. > > You can see the effect very clearly in any code path using the fallback > SkShader::Context::shadeSpan4f(). We shade legacy 8888, then > "linearize" to float by calling SkPM4f::FromPMColor(). At head we're > not really linearizing, which means everything ends up too bright in the > end. Things get double sRGB-encoded, etc. > > It is expected that this CL will make many color correct images look > darker and a lot more like legacy mode. It may be jarring... we've > gotten used to seeing this bug and thinking brighter == fixed. > > The only GM that changes in actual legacy 8888 is gamut, which > explicitly creates non-legacy 8888 images... the diff there is expected. > > Change-Id: I77ac6cfe8f7ffb15e90f4aad798dbe8f9d3aafbd > Reviewed-on: https://skia-review.googlesource.com/15227 > Commit-Queue: Mike Klein <mtklein@chromium.org> > Reviewed-by: Herb Derby <herb@google.com> > Reviewed-by: Mike Reed <reed@google.com> > TBR=mtklein@chromium.org,herb@google.com,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I80d852cbb618e94744f786bc82a4648128e99c71 Reviewed-on: https://skia-review.googlesource.com/15300 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* treat SkPMColor as sRGB in SkPM4f::FromPMColor()Gravatar Mike Klein2017-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | We made the wrong call in SkPM4f::FromPMColor(). SkPM4f::FromPMColor() is only used by the color correct drawing pipeline, not legacy. That means it makes a lot more sense to treat SkPMColors as premul sRGB than premul linear. You can see the effect very clearly in any code path using the fallback SkShader::Context::shadeSpan4f(). We shade legacy 8888, then "linearize" to float by calling SkPM4f::FromPMColor(). At head we're not really linearizing, which means everything ends up too bright in the end. Things get double sRGB-encoded, etc. It is expected that this CL will make many color correct images look darker and a lot more like legacy mode. It may be jarring... we've gotten used to seeing this bug and thinking brighter == fixed. The only GM that changes in actual legacy 8888 is gamut, which explicitly creates non-legacy 8888 images... the diff there is expected. Change-Id: I77ac6cfe8f7ffb15e90f4aad798dbe8f9d3aafbd Reviewed-on: https://skia-review.googlesource.com/15227 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Herb Derby <herb@google.com> Reviewed-by: Mike Reed <reed@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 16:00:23 +0000