aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkRasterPipelineBlitter.cpp
Commit message (Collapse)AuthorAge
* fix mask address calculationGravatar Mike Klein2018-02-26
| | | | | | | | | | | | | | | | | | | Switching the math from using fMaskPtr.stride to using mask.fRowBytes fixes the integer overflow here. However, if done naively it'd still do the math wrong, as mask.fRowBytes is stored as a uint32_t, and the 32-bit overflow still happens, silently. So we explicitly promote to size_t too. As a follow up we should consider turning on 'integer' sanitizer, which treats unsigned integer overflow as an error. Even though it's technically defined, it's likely not intended. Bug: skia:7563 Change-Id: Ia579d4f5615ed28180e6aaf3d4c3b54f516e655c Reviewed-on: https://skia-review.googlesource.com/110260 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Kevin Lubick <kjlubick@google.com>
* 1010102, 101010x, 888x in swGravatar Mike Klein2018-01-30
| | | | | | | | | | | | | | | | | | | Same sort of deal as before, now with all three new formats. While I was at it, I made sure RGBA 8888 and BGRA 8888 both work too. We don't want the 101010's in lowp, but 888x should be fine. After looking at the DM images on monitors at work, I decided to re-enable dither even on 10-bit images. Looking at the GMs in 888x or 101010x is interesting... I think we must not be clearing the memory allocated for layers? Seems like we want to allocate layers as 8888? Change-Id: I3a85b4f00877792a6425a7e7eb31eacb04ae9218 Reviewed-on: https://skia-review.googlesource.com/101640 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* remove append_from_srgb()Gravatar Mike Klein2017-12-18
| | | | | | | | | | | It's now no different than append(from_srgb). Bug: skia:7419 Change-Id: I97c59b6987f033ec2f1859db40ca3056b87b370a Reviewed-on: https://skia-review.googlesource.com/86741 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Rework out-of-gamut handling in SkRasterPipelineGravatar Mike Klein2017-12-18
| | | | | | | | | | | | | | | | | | | | | | Instead of trying to carefully manage the in-gamut / out-of-gamut state of the pipeline, let's do what a GPU would do, clamping to representable range in any float -> integer conversion. Most effects doing table lookups now clamp themselves internally, and the store_foo() methods clamp when the destination is fixed point. In turn the from_srgb() conversions and all future transfer function stages can care less about this stuff. If I'm thinking right, the _lowp side of things need not change at all, and that will soften the performance impact of this change. Anything that was fast to begin with was probably running a _lowp pipeline. Bug: skia:7419 Change-Id: Id2e080ac240a97b900a1ac131c85d9e15f70af32 Reviewed-on: https://skia-review.googlesource.com/85740 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Brian Osman <brianosman@google.com>
* "support" 3D masks like Ganesh doesGravatar Mike Klein2017-11-14
| | | | | | | | | | Ignore the mul and add planes and just use the A8 mask. It's better than not drawing anything at all. Change-Id: Ic20cec975c2db5c7aeb46ab7b430e8442dc8d8e9 Reviewed-on: https://skia-review.googlesource.com/71440 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* clean up SK_LEGACY_LOWP_STAGESGravatar Mike Klein2017-10-31
| | | | | | | Change-Id: I5629e74c4c13ddb9217fd3c2df3388030fa03f0c Reviewed-on: https://skia-review.googlesource.com/63780 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* add srcover_bgra_8888Gravatar Mike Klein2017-10-24
| | | | | | | | | | | | | | Chrome generally uses BGRA buffers, so srcover_rgba_8888 isn't really doing them any good. Probably a good idea to cover both kN32 options any time we specialize like this? There's one small diff, so I've lazily guarded this by SK_LEGACY_LOWP_STAGES, which I want to rebaseline today anyway. Change-Id: Ice672aa01a3fc83be0798580d6730a54df075478 Reviewed-on: https://skia-review.googlesource.com/63301 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Mike Reed <reed@google.com>
* impl blitAntiV2 via mask for rasterpipelineGravatar Mike Reed2017-09-06
| | | | | | | | Bug: skia: Change-Id: I3c34a9c38a86edc518abaf34982e1334a4154a15 Reviewed-on: https://skia-review.googlesource.com/43140 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* clean up some SkRasterPipelineBlitter TODOsGravatar Mike Klein2017-09-05
| | | | | | | | | | | | | | 1) remove the note about maybe implementing bitV()... we have. 2) rename append_load_d() to append_load_dst() to match how the stages are named (a long time ago they used to end with _d...) 3) move unpremul handling to append_load_dst() and append_store() to make it a bit easier to see how they nest with sRGB 4) remove append_blend()... it's now just SkBlendMode_AppendStages() Change-Id: Ic3280b66d8c1f26ef18a55044392f7d18fc29a75 Reviewed-on: https://skia-review.googlesource.com/42280 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
* fold params into StageRecGravatar Mike Reed2017-08-29
| | | | | | | | | | | | | pre-CL before trying to add a hint-rect field to allow shaders to "optimize" their stages for a given restriction in device space - e.g. if the shader's intrinsic domain is contained, it won't need to tile/clamp Bug: skia: Change-Id: Ia2da557691da25f31e4b9e3f53c3bc6709b89083 Reviewed-on: https://skia-review.googlesource.com/40224 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Reed <reed@google.com>
* add 'a8' config for nanobench, specialize blitV for raster-pipelineGravatar Mike Reed2017-08-28
| | | | | | | | | | Motivated by wanting to speed-up A8 blits in general (and at the moment, aarect blits). More to come in these areas. Bug: skia: Change-Id: I45e8ef951b8e89a825af72b1918049be10920137 Reviewed-on: https://skia-review.googlesource.com/39401 Reviewed-by: Yuqian Li <liyuqian@google.com> Commit-Queue: Mike Reed <reed@google.com>
* rework plus blend modeGravatar Mike Klein2017-08-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The most interesting parts of this are how plus interacts with partial coverage. Plus needs its clamp to happen after the lerp. Luckily, some of its math folds away: d' = clamp[ d*(1-c) + (s+d)*c ] == clamp[ d - dc + sc + dc ] == clamp[ d + sc ] What's nice there is that coverage can be folded into the src term. This suggests that we can re-write the plus stage to clamp internally (and thus, be viable for 8-bit) if we always pre-scale with coverage. We don't have a way to pre-scale with 565 coverage until now, but it's only a step or two away from there. We can use the alternate formulation we derived for alpha for lerp_565, calculating the alpha coverage from red, green, and blue coverages _and_ the values of src and dst alpha. While we already pre-scale srcover today for 8-bit or constant coverage, we cannot do the same for 565. When evaluating the expression d' = s + (1-a)d we need the a term to be pre-scaled with red's coverage when calculating dr', with blue's when calculating db', etc. Essentially we need to carry around a bunch of extra values, and we've got no way to do that. So instead, we'll just carefully pre-scale plus with any coverage, and keep post-lerping srcover when we have 565 coverage. Change-Id: I7a7a52eec7d482e1b98bb8a01ea0a3d5e67bef65 Reviewed-on: https://skia-review.googlesource.com/38300 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org>
* Revert "Consolidate SkRasterPipelineBlitter blendmode construction"Gravatar Florin Malita2017-08-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 19bf2b3a645c9e4129ee72e26541c4edea708393. Reason for revert: not going to cover all cases Original change's description: > Consolidate SkRasterPipelineBlitter blendmode construction > > Only blitAntiH & blitMask/kA8 for now, but hopefully we can extend for > blitRect & blitMask/kLCD16 also. > > Change-Id: I5e888d49c0c11f2f1fc595dbfb382044fc224edc > Reviewed-on: https://skia-review.googlesource.com/37542 > Reviewed-by: Mike Klein <mtklein@google.com> > Commit-Queue: Florin Malita <fmalita@chromium.org> TBR=mtklein@google.com,fmalita@chromium.org Change-Id: Ibd007bbc76f1bf8ec34998cc6ccb6b842792034c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/37860 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Consolidate SkRasterPipelineBlitter blendmode constructionGravatar Florin Malita2017-08-23
| | | | | | | | | | Only blitAntiH & blitMask/kA8 for now, but hopefully we can extend for blitRect & blitMask/kLCD16 also. Change-Id: I5e888d49c0c11f2f1fc595dbfb382044fc224edc Reviewed-on: https://skia-review.googlesource.com/37542 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Rename append_uniform_color() to append_constant_color().Gravatar Mike Klein2017-08-03
| | | | | | | | | | | | | | | | | The color appended here is both uniform and constant, and it's the constantness that makes this custom append method useful over just append(SkRasterPipeline::uniform_color, ...). Uniform colors that are not constant have to be loaded from the pointer each time (the caller might have changed the color out-of-band), but constant uniform colors can be analyzed once and implemented with specalizations like black_color and white_color. Change-Id: I3cfc00ccc578dd915367bca7113010557181224c Reviewed-on: https://skia-review.googlesource.com/30560 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Florin Malita <fmalita@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org>
* rough clamped tracking in SkRasterPipelineGravatar Mike Klein2017-07-25
| | | | | | | | | | This should make srgb_color_filter draw correctly in software. Previously the Rec2020 block would overflow. Change-Id: Ied4516728039e54214886d55bba92662beee9a26 Reviewed-on: https://skia-review.googlesource.com/26562 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* override SkRasterPipelineBlitter::blitRect()Gravatar Mike Klein2017-07-20
| | | | | | | | | | | Now that we can natively do 2D blits, it's time to invert the blitH() / blitRect() who-implements-whom relationship. blitRect() is our more fundamental blit. Change-Id: Ia0ae4a3cd75c7bbfc7bd5b08ff429193ce09a73b Reviewed-on: https://skia-review.googlesource.com/25361 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* convert over to 2d-modeGravatar Mike Klein2017-07-20
| | | | | | | | | | | | [√] convert all stages to use SkJumper_MemoryCtx / be 2d-compatible [√] convert compile to 2d also, remove 1d run/compile [√] convert all call sites [√] no diffs Change-Id: I3b806eb8fe0c3ec043359616409f7cd1211a1e43 Reviewed-on: https://skia-review.googlesource.com/24263 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org>
* experimental: draw into unpremulGravatar Mike Reed2017-07-19
| | | | | | | | | | raster-only Bug: skia: Change-Id: I3af19f031083c9cc258f73ba6a2f6020bb15f110 Reviewed-on: https://skia-review.googlesource.com/24400 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* add stages for black and white colorsGravatar Mike Reed2017-07-06
| | | | | | | | | | | | | | histogram of test skps: black: 1/7 white: 2/7 other: 4/7 Bug: skia: Change-Id: I3a092899d31ce87837e66e5c8ea9ec5e0f239361 Reviewed-on: https://skia-review.googlesource.com/21408 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Reed <reed@google.com>
* add bgra as 1st class formatGravatar Mike Klein2017-06-27
| | | | | | | | | | | | This is a start to eliminating swap_rb as a stage. I've just hit the main hot spots here. Going to look into the ~dozen other spots to see how they should work next. Change-Id: I26fb46a042facf7bd6fff3b47c9fcee86d7142fd Reviewed-on: https://skia-review.googlesource.com/20982 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Mike Reed <reed@google.com>
* specialize loaders for dst registers, to avoid move/swap stagesGravatar Mike Reed2017-06-27
| | | | | | | | Bug: skia: Change-Id: I75d82ef2226c5f116b7de2208c4e914739414b6d Reviewed-on: https://skia-review.googlesource.com/20984 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* support g8 and 4444 in SkRPBlitterGravatar Mike Klein2017-06-17
| | | | | | | | | BUG=skia:6766 Change-Id: I1bf8720cac24092352fd99d8d509252a10270b54 Reviewed-on: https://skia-review.googlesource.com/20020 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* remove dead code associated with SK_SUPPORT_LEGACY_RASTERPIPELINEGravatar Mike Reed2017-06-12
| | | | | | | | | | | | | Now we just look at the paint to decide if the user wants to dither. Needs this to land first: https://skia-review.googlesource.com/c/19448/ Bug: skia: Change-Id: I31940696e114922bcc8fb9ca3c24c2eb0a622800 Reviewed-on: https://skia-review.googlesource.com/19496 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* CanOverflow -> ClampIfNeededGravatar Mike Klein2017-06-09
| | | | | | | | | Centralize the clamping in ClampIfNeeded, and switch it to clamp_1. Change-Id: I056ac029d3ddc81e3f0f194f2b9c9924cad4caae Reviewed-on: https://skia-review.googlesource.com/19401 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Reed <reed@google.com>
* Opt-in burst mechanism for pipeline shadersGravatar Florin Malita2017-06-06
| | | | | | | | | | | | | | Add a dedicated virtual for shaders to select burst mode. Enabled for linear gradients with more than 8 stops, as a start. BUG=skia:6710 Change-Id: I1b19124f42d1d805de27a5db6a26601c386bb9ff Reviewed-on: https://skia-review.googlesource.com/18628 Commit-Queue: Florin Malita <fmalita@chromium.org> Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* implement SkRasterPipelineBlitter::blitAntiH2()Gravatar Mike Klein2017-06-05
| | | | | | | | | | The default blitAntiH2() calls blitAntiH() with two length-1 runs, but for this blitter creating a small mask is better. We can stamp both pixels out with a single pipeline invocation. Change-Id: If356975e85310a4545e54f2231a142d6e537944d Reviewed-on: https://skia-review.googlesource.com/18581 Reviewed-by: Mike Reed <reed@google.com>
* default impl of appendStages now calls shaderContextGravatar Mike Reed2017-06-02
| | | | | | | | | | | | | | | | | | this is approximately a revert of https://skia-review.googlesource.com/c/17768/ I propose if/when we want to experiment with a fast-path for coherent shaders (e.g. 2-color linear gradients, up-scaling images) that we just create a new mechanism for shaders to opt into that, knowing that it will be driven by the rasterpipeline (and never by the old context convention). This CL now makes it legal/clear that a new shader subclass can *just* implement stages for raster, and never needs to make a context. Bug: skia: Change-Id: I525a8b1cece100f0993f75e28128e0927a4ea35c Reviewed-on: https://skia-review.googlesource.com/18481 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* have shaders that need seed_shader call it themselvesGravatar Mike Klein2017-06-01
| | | | | | | | | | | | This ought to make compose shader and our sprite blitter a bit more efficient. Compose shader can simply re-seed instead of saving the xy values off to a buffer. The sprite blitter doesn't need xy at all. Change-Id: Ib4b3509288810f74a4c8e2978ce2ca14d8644980 Reviewed-on: https://skia-review.googlesource.com/18405 Reviewed-by: Herb Derby <herb@google.com> Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* plumb y through to SkJumperGravatar Mike Klein2017-06-01
| | | | | | | | | | | | | | | There'll still be a little more refactoring after this, but this is the main thing we want to do. This makes y available in a general-purpose register in pipeline stages, just like x. Stages that need y (seed_shader and dither) can just use it rather than pulling it off a context pointer. seed_shader loses its context pointer, and dither's gets simpler. Change-Id: Ic2d1e13b03fb45b73e308b38aafbb3a14c29cf7f Reviewed-on: https://skia-review.googlesource.com/18383 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* update SkRasterPipeline::run() to also take yGravatar Mike Klein2017-06-01
| | | | | | | | | y isn't used yet. This is just a warmup that updates the callers. Change-Id: I78f4f44e2b82f72b3a39fa8a8bdadef1d1b8a99e Reviewed-on: https://skia-review.googlesource.com/18381 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* rasterpipeline:Gravatar Mike Reed2017-05-26
| | | | | | | | | | | | | | + only dither if the paint asks for it - don't special case if the shader is a gradient guard: SK_SUPPORT_LEGACY_RASTERPIPELINE Bug: skia: Change-Id: I7f0c101049e5cb32a80306dcfff3bc21bcf318be Reviewed-on: https://skia-review.googlesource.com/17931 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org>
* add srcover_rgba_8888Gravatar Mike Klein2017-05-25
| | | | | | | Change-Id: Iabdc79183ccd2f9cc513d4bdc530fb078b1627ab Reviewed-on: https://skia-review.googlesource.com/17930 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Reland of SkShaderBaseGravatar Florin Malita2017-05-25
| | | | | | | | | | Introduce a private base class (SkShaderBase), to hide implementation details from the public interface (SkShader). Change-Id: Ib1d76cde880bd51868b97408710f8bb38128e536 Reviewed-on: https://skia-review.googlesource.com/17925 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Revert "SkShaderBase"Gravatar Florin Malita2017-05-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 58a756435ca3700d9766a4580bb0771a9774f603. Reason for revert: g3, Android borkage. Original change's description: > SkShaderBase > > Introduce a private base class (SkShaderBase), to hide > implementation details from the public interface (SkShader). > > Change-Id: If3ec26ca6abc9da20e3f139c11fdc023bdd85176 > Reviewed-on: https://skia-review.googlesource.com/17241 > Commit-Queue: Florin Malita <fmalita@chromium.org> > Reviewed-by: Mike Reed <reed@google.com> > TBR=mtklein@google.com,fmalita@chromium.org,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I32b012ee466dd006c074593f211f43ed602f1078 Reviewed-on: https://skia-review.googlesource.com/17845 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Florin Malita <fmalita@chromium.org>
* SkShaderBaseGravatar Florin Malita2017-05-24
| | | | | | | | | | Introduce a private base class (SkShaderBase), to hide implementation details from the public interface (SkShader). Change-Id: If3ec26ca6abc9da20e3f139c11fdc023bdd85176 Reviewed-on: https://skia-review.googlesource.com/17241 Commit-Queue: Florin Malita <fmalita@chromium.org> Reviewed-by: Mike Reed <reed@google.com>
* add a bulk shader path through SkRasterPipelineBlitterGravatar Mike Klein2017-05-24
| | | | | | | | Change-Id: I76f1f0c29b3408bffb7732ee1afb8337c478605e Reviewed-on: https://skia-review.googlesource.com/17768 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org> Reviewed-by: Herb Derby <herb@google.com>
* SkRasterPipeline in SkArenaAllocGravatar Mike Klein2017-05-24
| | | | | | | | | Bug: skia:6673 Change-Id: Ia2bae4f6a9039a007a10b6b45bcf2f0854bf6e5c Reviewed-on: https://skia-review.googlesource.com/17794 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Revert "Revert "mark SkRasterPipelineBlitter final""Gravatar Mike Klein2017-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b5b26a9d2999825ba8f405b8c37d33d49a529369. Reason for revert: this one's probably fine too Original change's description: > Revert "mark SkRasterPipelineBlitter final" > > This reverts commit 317a1857f80ffc18d591dd6b1ac0988184b1ed2b. > > Reason for revert: Valgrind requires reverting ancestor commit. > > Original change's description: > > mark SkRasterPipelineBlitter final > > > > This devirtualizes the call from blitAntiH to blitH, > > and makes sure no future self calls will be virtual. > > > > Change-Id: I2a277bbc1450a96e07794791792d59e5f806bde0 > > Reviewed-on: https://skia-review.googlesource.com/17418 > > Commit-Queue: Mike Klein <mtklein@chromium.org> > > Reviewed-by: Mike Klein <mtklein@chromium.org> > > > > TBR=mtklein@chromium.org,herb@google.com,reed@google.com > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Change-Id: Ic726fd6b9bf18c397812ecc256353ab4a0a336c5 > Reviewed-on: https://skia-review.googlesource.com/17522 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Brian Osman <brianosman@google.com> > TBR=mtklein@chromium.org,herb@google.com,reviews@skia.org,brianosman@google.com,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: Ic27fbfaab9d040a1ef49d596350649096b908ea3 Reviewed-on: https://skia-review.googlesource.com/17528 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
* Revert "mark SkRasterPipelineBlitter final"Gravatar Brian Osman2017-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 317a1857f80ffc18d591dd6b1ac0988184b1ed2b. Reason for revert: Valgrind requires reverting ancestor commit. Original change's description: > mark SkRasterPipelineBlitter final > > This devirtualizes the call from blitAntiH to blitH, > and makes sure no future self calls will be virtual. > > Change-Id: I2a277bbc1450a96e07794791792d59e5f806bde0 > Reviewed-on: https://skia-review.googlesource.com/17418 > Commit-Queue: Mike Klein <mtklein@chromium.org> > Reviewed-by: Mike Klein <mtklein@chromium.org> > TBR=mtklein@chromium.org,herb@google.com,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: Ic726fd6b9bf18c397812ecc256353ab4a0a336c5 Reviewed-on: https://skia-review.googlesource.com/17522 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
* mark SkRasterPipelineBlitter finalGravatar Mike Klein2017-05-22
| | | | | | | | | | This devirtualizes the call from blitAntiH to blitH, and makes sure no future self calls will be virtual. Change-Id: I2a277bbc1450a96e07794791792d59e5f806bde0 Reviewed-on: https://skia-review.googlesource.com/17418 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Mike Klein <mtklein@chromium.org>
* add compile, use it in blitterGravatar Mike Klein2017-05-22
| | | | | | | | | | | | I expanded an existing bench to show off the difference: SkRasterPipeline_… 300 …compile 1x …run 1.14x Change-Id: I5d63d602cda3f78d2d0891fcc85baf5514632900 Reviewed-on: https://skia-review.googlesource.com/17458 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Herb Derby <herb@google.com>
* refactor SkRasterPipelineBlitterGravatar Mike Klein2017-05-22
| | | | | | | | | | | | | | | | | This refactors the factories so that the create-from-paint factory is a front-patch to the create-from-shader-pipeline factory. Feature-wise, we make the pre-baked shader pipeline responsible for modulating by paint alpha; the factory only adds when creating from the paint. We can fold the alpha into the colors in drawVertices, which makes it run a bit faster, dropping the need for a scale_1_float runtime stage. This causes a few invisible diffs on the "vertices" GM, but everything else draws the same. Change-Id: I3eeacc9aafbce2023ab18991bbb68c35645e9387 Reviewed-on: https://skia-review.googlesource.com/17395 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* stage version of verticesGravatar Mike Reed2017-05-19
| | | | | | | | | | | | | | | | This CL, just to limit its size/complexity, only handles colors but not textures. Future CLs will cover everything. Performance is pretty exciting. Its faster than the old code-path, and when we fix a bug in pathutils to preserve opaqueness, it gets a lot faster (8 -> 5) Bug: skia: Change-Id: I4113060e25fe25fe4e6a0ea59bd4fa5e33abc668 Reviewed-on: https://skia-review.googlesource.com/17276 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org>
* 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>
* 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>
* "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>
* 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>
* 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>
* dither stageGravatar Mike Klein2017-05-03
| | | | | | | | | | | | | | | | I think we can dither generically as a pipeline stage. I'm not married to where the dither happens, or the implementation, which is mostly cribbed from https://en.wikipedia.org/wiki/Ordered_dithering. BUG=skia:3302,skia:6224 Change-Id: If7f6b22a523ca0b34cb03c0aa97b6734c34e0133 Reviewed-on: https://skia-review.googlesource.com/15161 Commit-Queue: Mike Klein <mtklein@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org> Reviewed-by: Herb Derby <herb@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 12:42:25 +0000