aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/effects/gradients
Commit message (Collapse)AuthorAge
* Reducing number of calls to GLSL mix() from two to one reduces frame render ↵Gravatar fmenozzi2016-08-16
| | | | | | | | | time by 21% BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2247113003 Review-Url: https://codereview.chromium.org/2247113003
* Add specialized code for hard stop gradients on GPUGravatar fmenozzi2016-08-15
| | | | | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2223203003 Committed: https://skia.googlesource.com/skia/+/0c63006b88a16e3418d92852a62771615799839d Committed: https://skia.googlesource.com/skia/+/99818d69372d29a139935cfe5c379e491432931b Committed: https://skia.googlesource.com/skia/+/2a4959181fc98d5d7ee862e7cd1c7993b3343be6 Review-Url: https://codereview.chromium.org/2223203003
* Revert of Exact Ganesh Gradients for Special Cases (patchset #9 id:160001 of ↵Gravatar halcanary2016-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/2223203003/ ) Reason for revert: specualtive revert to fix valgrind bot Perf-Ubuntu-GCC-ShuttleA-GPU-GTX550Ti-x86_64-Release-Valgrind Original issue's description: > Remove generalized gradient code > > BUG=skia: > GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2223203003 > > Committed: https://skia.googlesource.com/skia/+/0c63006b88a16e3418d92852a62771615799839d > Committed: https://skia.googlesource.com/skia/+/99818d69372d29a139935cfe5c379e491432931b > Committed: https://skia.googlesource.com/skia/+/2a4959181fc98d5d7ee862e7cd1c7993b3343be6 TBR=bsalomon@google.com,fmenozzi@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review-Url: https://codereview.chromium.org/2245533005
* Remove generalized gradient codeGravatar fmenozzi2016-08-12
| | | | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2223203003 Committed: https://skia.googlesource.com/skia/+/0c63006b88a16e3418d92852a62771615799839d Committed: https://skia.googlesource.com/skia/+/99818d69372d29a139935cfe5c379e491432931b Review-Url: https://codereview.chromium.org/2223203003
* Revert of Exact Ganesh Gradients for Special Cases (patchset #8 id:140001 of ↵Gravatar halcanary2016-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/2223203003/ ) Reason for revert: Chrome iOS build break https://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds/50777/steps/compile/logs/stdio error: unused function 'close_to_one_half' Original issue's description: > Remove generalized gradient code > > BUG=skia: > GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2223203003 > > Committed: https://skia.googlesource.com/skia/+/0c63006b88a16e3418d92852a62771615799839d > Committed: https://skia.googlesource.com/skia/+/99818d69372d29a139935cfe5c379e491432931b TBR=bsalomon@google.com,fmenozzi@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review-Url: https://codereview.chromium.org/2241483003
* Remove generalized gradient codeGravatar fmenozzi2016-08-11
| | | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2223203003 Committed: https://skia.googlesource.com/skia/+/0c63006b88a16e3418d92852a62771615799839d Review-Url: https://codereview.chromium.org/2223203003
* Revert "Remove generalized gradient code"Gravatar fmenozzi2016-08-10
| | | | | | | | | | This reverts commit 0c63006b88a16e3418d92852a62771615799839d. BUG=skia: NOTREECHECKS=true GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2235953003 Review-Url: https://codereview.chromium.org/2235953003
* SkGradientShader.cpp: fix build when SK_SUPPORT_GPU=0Gravatar halcanary2016-08-10
| | | | | | | NOTRY=true GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2235863002 Review-Url: https://codereview.chromium.org/2235863002
* Remove generalized gradient codeGravatar fmenozzi2016-08-10
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2223203003 Review-Url: https://codereview.chromium.org/2223203003
* Prevent degenerate linear gradient instantiationGravatar fmalita2016-08-10
| | | | | | | | | | If the point distance exceeds SkScalar, nasty things tend to happen. R=reed@google.com BUG=636194 GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2234663002 Review-Url: https://codereview.chromium.org/2234663002
* Refactor various gradient effect classesGravatar fmenozzi2016-08-09
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2221133002 Review-Url: https://codereview.chromium.org/2221133002
* Add destination color space to AsFPArgs. Eliminates last XFORMTODO.Gravatar brianosman2016-07-25
| | | | | | | | | | | | This is going to be needed in many more places as I finish connecting the dots. Even better - I'd like to switch to a world where SkColorSpace != nullptr is the only signal we use for gamma-correct rendering, so I can eliminate SkSourceGammaTreatment and SkSurfaceProps::isGammaCorrect. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2180503002 Review-Url: https://codereview.chromium.org/2180503002
* Bundle SkShader::asFragmentProcessor arguments in a structGravatar brianosman2016-07-22
| | | | | | | | | | The signature of this thing keeps changing (and is about to change again). This just makes maintenance much easier. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2175563003 Review-Url: https://codereview.chromium.org/2175563003
* Correct sRGB <-> linear everywhere.Gravatar mtklein2016-07-20
| | | | | | | | | | | | | | | | | | | | | | This trims the SkPM4fPriv methods down to just foolproof methods. (Anything trying to build these itself is probably wrong.) Things like Sk4f srgb_to_linear(Sk4f) can't really exist anymore, at least not efficiently, so this refactor is somewhat more invasive than you might think. Generally this means things using to_4f() are also making a misstep... that's gone too. It also does not make sense to try to play games with linear floats with 255 bias any more. That hack can't work with real sRGB coding. Rather than update them, I've removed a couple of L32 xfermode fast paths. I'd even rather drop it entirely... BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2163683002 CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot Review-Url: https://codereview.chromium.org/2163683002
* Clarify GrGradientEffect key enumGravatar fmenozzi2016-07-19
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2158323003 Review-Url: https://codereview.chromium.org/2158323003
* Improve naive SkColorXform to half floatsGravatar msarett2016-07-19
| | | | | | | | | | | | | | | | | | | | | | | | This should give us a good baseline to explore using SkRasterPipeline. A particular colorxform to half float drops from 425us to 282us on my desktop. Color Xform to Half Float (HP z620) Original 425us Trans16 (not 32) 355us Vector Trans16 378us Trans16 + Keep Halfs in Vector 335us Vector Trans16 + Keep Halfs in Vector 282us Final 282us Color Xform to Half Float (Nexus 5X) Original 556us Final 472us BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2159993003 CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot Review-Url: https://codereview.chromium.org/2159993003
* Expand _01 half<->float limitation to _finite. Simplify.Gravatar mtklein2016-07-15
| | | | | | | | | | | | | | | | | | | | | | | It's become clear we need to sometimes deal with values <0 or >1. I'm not yet convinced we care about NaN or +-inf. We had some fairly clever tricks and optimizations here for NEON and SSE. I've thrown them out in favor of a single implementation. If we find the specializations mattered, we can certainly figure out how to extend them to this new range/domain. This happens to add a vectorized float -> half for ARMv7, which was missing from the _01 version. (The SSE strategy was not portable to platforms that flush denorm floats to zero.) I've tested the full float range for FloatToHalf on my desktop and a 5x. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2145663003 CQ_INCLUDE_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Fast-Trybot Committed: https://skia.googlesource.com/skia/+/3296bee70d074bb8094b3229dbe12fa016657e90 Review-Url: https://codereview.chromium.org/2145663003
* Revert of Expand _01 half<->float limitation to _finite. Simplify. ↵Gravatar mtklein2016-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #7 id:120001 of https://codereview.chromium.org/2145663003/ ) Reason for revert: Unit tests fail on Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Fast Original issue's description: > Expand _01 half<->float limitation to _finite. Simplify. > > It's become clear we need to sometimes deal with values <0 or >1. > I'm not yet convinced we care about NaN or +-inf. > > We had some fairly clever tricks and optimizations here for NEON > and SSE. I've thrown them out in favor of a single implementation. > If we find the specializations mattered, we can certainly figure out > how to extend them to this new range/domain. > > This happens to add a vectorized float -> half for ARMv7, which was > missing from the _01 version. (The SSE strategy was not portable to > platforms that flush denorm floats to zero.) > > I've tested the full float range for FloatToHalf on my desktop and a 5x. > > BUG=skia: > GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2145663003 > CQ_INCLUDE_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Fast-Trybot > > Committed: https://skia.googlesource.com/skia/+/3296bee70d074bb8094b3229dbe12fa016657e90 TBR=msarett@google.com,mtklein@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review-Url: https://codereview.chromium.org/2151023003
* Expand _01 half<->float limitation to _finite. Simplify.Gravatar mtklein2016-07-14
| | | | | | | | | | | | | | | | | | | | | | It's become clear we need to sometimes deal with values <0 or >1. I'm not yet convinced we care about NaN or +-inf. We had some fairly clever tricks and optimizations here for NEON and SSE. I've thrown them out in favor of a single implementation. If we find the specializations mattered, we can certainly figure out how to extend them to this new range/domain. This happens to add a vectorized float -> half for ARMv7, which was missing from the _01 version. (The SSE strategy was not portable to platforms that flush denorm floats to zero.) I've tested the full float range for FloatToHalf on my desktop and a 5x. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2145663003 CQ_INCLUDE_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot Review-Url: https://codereview.chromium.org/2145663003
* Check PremulType during GrGradientEffect::onIsEqualGravatar csmartdalton2016-06-27
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2100223003 Review-Url: https://codereview.chromium.org/2100223003
* update callers to not use SkColorProfileTypeGravatar reed2016-06-21
| | | | | | | | | Requires https://codereview.chromium.org/2087833002/ to land first. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2086583002 Review-Url: https://codereview.chromium.org/2086583002
* sk_sp for Ganesh.Gravatar bungeman2016-06-09
| | | | | | | | | | Convert use of GrFragmentProcessor, GrGeometryProcessor, and GrXPFactory to sk_sp. This clarifies ownership and should reduce reference count churn by moving ownership. GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2041113004 Review-Url: https://codereview.chromium.org/2041113004
* SkLeanWindows.h: #include "Windows.h" fewer placesGravatar halcanary2016-06-07
| | | | | | | | | | | | | | | | | | | | | | | | $ git grep -l '<windows.h>' include src include/private/SkLeanWindows.h $ git grep -l SkLeanWindows.h | grep '\.h$' include/ports/SkTypeface_win.h include/utils/win/SkHRESULT.h include/utils/win/SkTScopedComPtr.h include/views/SkEvent.h src/core/SkMathPriv.h src/ports/SkTypeface_win_dw.h src/utils/SkThreadUtils_win.h src/utils/win/SkWGL.h The same for `#include <intrin.h>` that was found in SkMath.h. Those functions that needed it are moved to SkMathPriv.h. GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2041943002 CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_compile_dbg_ng,win_chromium_compile_rel_ng Review-Url: https://codereview.chromium.org/2041943002
* linear -> sRGB: use fast approximate sqrt()Gravatar mtklein2016-06-07
| | | | | | | | | | | | | | | | Since we're already approximating the sRGB gamma curve with a sqrt(), we might as well approximate with it a faster approximate sqrt(). On Intel, this .rsqrt().invert() version is 2-3x faster than .sqrt() (~3x faster on older machines, ~2x faster on newer machines). This should provide ~11 bits of precision, suspiciously exactly enough. Running dm --config srgb, there are diffs, but none perceptible. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2046063002 Review-Url: https://codereview.chromium.org/2046063002
* Add new SkSourceGammaTreatment enum, used in situations like mipmap ↵Gravatar brianosman2016-06-06
| | | | | | | | | construction, where we need to know if we should respect (vs. ignore) the gamma encoding of sRGB tagged images. Plumb that extensively. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2037413002 Review-Url: https://codereview.chromium.org/2037413002
* Silence ASAN int32 overflow warningGravatar fmalita2016-05-26
| | | | | | | | | | | It's fine to overflow SK_MaxS32 by one, the subsequent cast ensures correct clamping. But we need to cast earlier in order to make ASAN happy. TBR=mtklein@google.com,reed@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2013243002 Review-Url: https://codereview.chromium.org/2013243002
* Fix int32 overflow in LinearGradientContext::shade4_dx_clampGravatar fmalita2016-05-26
| | | | | | | | | | | | | | The unconditional increment in shade4_dx_clamp can overflow int32 => n == SK_MinS32 => count ~= SK_MinS32 => we skip the main shader loop 'cause count < 0 R=reed@google.com,mtklein@google.com BUG=chromium:599458 GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2010843002 Review-Url: https://codereview.chromium.org/2010843002
* Harden linear gradientsGravatar fmalita2016-05-11
| | | | | | | | | | | Ensure that the last offset == 1.0f when implict positions are used (previously subject to float imprecision). BUG=skia:5288,chromium:598484 R=reed@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1974463002 Review-Url: https://codereview.chromium.org/1974463002
* Revert of SK_DECLARE_STATIC_MUTEX -> static SkMutex (patchset #1 id:1 of ↵Gravatar reed2016-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1948193002/ ) Reason for revert: broken the Mac and Linux builders, e.g.: https://build.chromium.org/p/chromium/builders/Mac/builds/15151 https://build.chromium.org/p/chromium/builders/Linux%20x64/builds/19052 Original issue's description: > SK_DECLARE_STATIC_MUTEX -> static SkMutex > > There's no need to use a macro to declare static SkMutexes any more > (and there's likewise no need to restrict them to global scope). > > BUG=skia: > GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1948193002 > > Committed: https://skia.googlesource.com/skia/+/5e56cfd3fa1041dbb83899844fb92fa9a2ef1009 TBR=mtklein@google.com,mtklein@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review-Url: https://codereview.chromium.org/1945353003
* SK_DECLARE_STATIC_MUTEX -> static SkMutexGravatar mtklein2016-05-04
| | | | | | | | | | There's no need to use a macro to declare static SkMutexes any more (and there's likewise no need to restrict them to global scope). BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1948193002 Review-Url: https://codereview.chromium.org/1948193002
* Refactor how we store and use samplers in GaneshGravatar egdaniel2016-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The main goal of this refactorization is to allow Vulkan to use separate sampler and texture objects in the shader and descriptor sets and combine them into a sampler2d in the shader where needed. A large part of this is separating how we store samplers and uniforms in the UniformHandler. We no longer need to store handles to samplers besides when we are initially emitting code. After we emit code all we ever do is loop over all samplers and do some processor independent work on them, so we have no need for direct access to individual samplers. In the GLProgram all we ever do is set the sampler uniforms in the ctor and never touch them again, so no need to save sampler info there. The texture access on program reuse just assume that they come in the same order as we set the texture units for the samplers For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers, then when we get new textures, we just assume they come in in the same order as we set the samplers on the descriptor sets. Thus no need to save direct vulkan info. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004 Committed: https://skia.googlesource.com/skia/+/45b61a1c4c0be896e7b12fd1405abfece799114f Review URL: https://codereview.chromium.org/1885863004
* Revert of Refactor how we store and use samplers in Ganesh (patchset #7 ↵Gravatar egdaniel2016-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:120001 of https://codereview.chromium.org/1885863004/ ) Reason for revert: breaking bots Original issue's description: > Refactor how we store and use samplers in Ganesh > > The main goal of this refactorization is to allow Vulkan to use separate > sampler and texture objects in the shader and descriptor sets and combine > them into a sampler2d in the shader where needed. > > A large part of this is separating how we store samplers and uniforms in the > UniformHandler. We no longer need to store handles to samplers besides when > we are initially emitting code. After we emit code all we ever do is loop over > all samplers and do some processor independent work on them, so we have no need > for direct access to individual samplers. > > In the GLProgram all we ever do is set the sampler uniforms in the ctor and never > touch them again, so no need to save sampler info there. The texture access on > program reuse just assume that they come in the same order as we set the texture > units for the samplers > > For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers, > then when we get new textures, we just assume they come in in the same order as we > set the samplers on the descriptor sets. Thus no need to save direct vulkan info. > > BUG=skia: > GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004 > > Committed: https://skia.googlesource.com/skia/+/45b61a1c4c0be896e7b12fd1405abfece799114f TBR=bsalomon@google.com,jvanverth@google.com,cdalton@nvidia.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1896013003
* Refactor how we store and use samplers in GaneshGravatar egdaniel2016-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | The main goal of this refactorization is to allow Vulkan to use separate sampler and texture objects in the shader and descriptor sets and combine them into a sampler2d in the shader where needed. A large part of this is separating how we store samplers and uniforms in the UniformHandler. We no longer need to store handles to samplers besides when we are initially emitting code. After we emit code all we ever do is loop over all samplers and do some processor independent work on them, so we have no need for direct access to individual samplers. In the GLProgram all we ever do is set the sampler uniforms in the ctor and never touch them again, so no need to save sampler info there. The texture access on program reuse just assume that they come in the same order as we set the texture units for the samplers For Vulkan, it is a similar story. We create the descriptor set layouts with the samplers, then when we get new textures, we just assume they come in in the same order as we set the samplers on the descriptor sets. Thus no need to save direct vulkan info. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1885863004 Review URL: https://codereview.chromium.org/1885863004
* Modernize and trim down SkOnce.Gravatar mtklein2016-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | The API and implementation are very much simplified. You may not want to bother reading the diff. As is our trend, SkOnce now uses <atomic> directly. Member initialization means we don't need SK_DECLARE_STATIC_ONCE. SkSpinlock already works this same way. All uses of the old API taking an external bool* and Lock* were pessimal, so I have not carried this sort of API forward. It's simpler, faster, and more space-efficient to always use this single SkOnce class interface. SkOnce weighs 2 bytes: a done bool and an SkSpinlock, also a bool internally. This API refactoring opens up the opportunity to fuse those into a single three-state byte if we'd like. No public API changes. TBR=reed@google.com BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1894893002 Review URL: https://codereview.chromium.org/1894893002
* Observe gTreatSkColorAsSRGB for 4f gradients.Gravatar fmalita2016-04-15
| | | | | | | | | | Use SkColor4f::FromColor() in the color packer to convert srgb->linear when needed. R=reed@google.com,herb@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890253002 Review URL: https://codereview.chromium.org/1890253002
* Rename EmitArgs::fSamplers to fTexSamplersGravatar cdalton2016-04-11
| | | | | | | | | | | Renames fSamplers to fTexSamplers in GrProcessor EmitArgs, and renames GrGLSLTextureSampler to GrGLSLSampler. This will allow us to add a second array of buffer samplers. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1862373003 Review URL: https://codereview.chromium.org/1862373003
* Revert of For *ToFixed, in debug mode, assert that the value is in range. ↵Gravatar fmalita2016-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #6 id:140001 of https://codereview.chromium.org/1824733002/ ) Reason for revert: Asserts in Blink rolls: https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/84520/layout-test-results/results.html STDERR: [1:1:0407/120919:1455366829:INFO:SkFixed.h(88)] ../../third_party/skia/include/private/SkFixed.h:88: fatal error: ""truncf(x * (1 << 16)) == static_cast<float> Original issue's description: > For *ToFixed, in debug mode, assert that the value is in range. > > Use SkFloatPinToFixed in SkTwoPointConicalGradient.cpp because it is failing in DM. fmalita is working on replacing this code with the 4f version, so I'm not bothering to fix it. (The beginnings of a real fix are in https://codereview.chromium.org/1767163003, which I do not plan to commit.) > > BUG=skia:4632 > GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1824733002 > > Committed: https://skia.googlesource.com/skia/+/93dc33972cd6a418e84270298b856d2de08d9c1c TBR=mtklein@google.com,reed@google.com,benjaminwagner@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia:4632 Review URL: https://codereview.chromium.org/1868933004
* [4fGradient] Veto blitters for non-opaque paintsGravatar fmalita2016-04-07
| | | | | | | | | | | | | | The current blitters don't support SrcOver, so we must ensure the colors are opaque. Checking shader.colorsAreOpaque() is not enough as it doesn't reflect the paint alpha. Instead we should check for context flags & kOpaqueAlpha_Flag, which is only set when both the color stops AND the paint are opaque. R=reed@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1870773002 Review URL: https://codereview.chromium.org/1870773002
* For *ToFixed, in debug mode, assert that the value is in range.Gravatar benjaminwagner2016-04-07
| | | | | | | | | Use SkFloatPinToFixed in SkTwoPointConicalGradient.cpp because it is failing in DM. fmalita is working on replacing this code with the 4f version, so I'm not bothering to fix it. (The beginnings of a real fix are in https://codereview.chromium.org/1767163003, which I do not plan to commit.) BUG=skia:4632 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1824733002 Review URL: https://codereview.chromium.org/1824733002
* change flattenable factory to return sk_spGravatar reed2016-04-03
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1855733002 Review URL: https://codereview.chromium.org/1855733002
* Style bikeshed - remove extraneous whitespaceGravatar halcanary2016-03-29
| | | | | | GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1842753002 Review URL: https://codereview.chromium.org/1842753002
* Planar ramp() for S32 linear gradientsGravatar fmalita2016-03-23
| | | | | | | R=mtklein@google.com,reed@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1825333003 Review URL: https://codereview.chromium.org/1825333003
* Refactor 4f gradients using trait templatesGravatar fmalita2016-03-21
| | | | | | | | | | | | | | | | Some 4f gradient housekeeping. 1) replace <DstPtrType, ColorProfile> specialization tuples with an enum covering all dest types (L32, S32, F16, F32) 2) group various template helpers into dest trait classes, specialized for each dest type (2a - conflate current dst_swizzle and scale_for_dest ops into one load op) R=reed@google.com,mtklein@google.com,herb@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1816883002 Review URL: https://codereview.chromium.org/1816883002
* SkNx refreshGravatar mtklein2016-03-21
| | | | | | | | | | | | | | | | | | | | - rearrange a bit - fewer macros - hooks for all operators - add left and right scalar operator overrides - add +=, &=, <<=, etc. - add SkNx_split() and SkNx_join() - simplify the many rsqrt() and invert() options to just what we actually use This refactoring pointed out that our float <-> int NEON conversions are not specialized, so I've implemented them. It seems nice that this is an error rather than silently falling back to serial code. It's unclear to me if split/join want to be external, static methods, or non-static methods (SkNx_join(), Sk4f::Join(), x.join()). Time will tell? BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1812233003 CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot;client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot Review URL: https://codereview.chromium.org/1812233003
* sRGB support in Ganesh. Several pieces:Gravatar brianosman2016-03-21
| | | | | | | | | | | | | | | | | | | | | | sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows us to disable sRGB -> Linear conversion when reading textures. This gives us an easy way to support "legacy" L32 mode. We disable decoding based on the pixel config of the render target. Textures can override that behavior (specifically for format-conversion draws where we want that behavior). Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA internally, and the external format is BGR order, so TexImage calls will swizzle correctly. This lets us interact with sRGB raster surfaces on BGR platforms. Devices without sRGB support behave like they always have: conversion from color type and profile type ignores sRGB and always returns linear pixel configs. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002 Review URL: https://codereview.chromium.org/1789663002
* allow more options for shader blitprocsGravatar reed2016-03-18
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1810383004 Review URL: https://codereview.chromium.org/1810383004
* 4f linear gradient shader blittersGravatar fmalita2016-03-18
| | | | | | | | | | | | Add F16 specializations to support writing to half-float dests. Add color profile template arg across the board to support writing to sRGB dests. R=reed@google.com,mtklein@google.com,herb@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1808963005 Review URL: https://codereview.chromium.org/1808963005
* Revert of sRGB support in Ganesh. Several pieces: (patchset #12 id:220001 of ↵Gravatar brianosman2016-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1789663002/ ) Reason for revert: We're getting sRGB non-8888 configs? Original issue's description: > sRGB support in Ganesh. Several pieces: > > sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows > us to disable sRGB -> Linear conversion when reading textures. This gives > us an easy way to support "legacy" L32 mode. We disable decoding based on > the pixel config of the render target. Textures can override that behavior > (specifically for format-conversion draws where we want that behavior). > > Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA > internally, and the external format is BGR order, so TexImage calls will > swizzle correctly. This lets us interact with sRGB raster surfaces on BGR > platforms. > > Devices without sRGB support behave like they always have: conversion from > color type and profile type ignores sRGB and always returns linear pixel > configs. > > BUG=skia: > GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002 > > Committed: https://skia.googlesource.com/skia/+/9e3f1bf4e5cd8fc59554f986f36d6b034e99f9eb TBR=reed@google.com,bsalomon@google.com,robertphillips@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1814533003
* sRGB support in Ganesh. Several pieces:Gravatar brianosman2016-03-17
| | | | | | | | | | | | | | | | | | | | | | sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows us to disable sRGB -> Linear conversion when reading textures. This gives us an easy way to support "legacy" L32 mode. We disable decoding based on the pixel config of the render target. Textures can override that behavior (specifically for format-conversion draws where we want that behavior). Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA internally, and the external format is BGR order, so TexImage calls will swizzle correctly. This lets us interact with sRGB raster surfaces on BGR platforms. Devices without sRGB support behave like they always have: conversion from color type and profile type ignores sRGB and always returns linear pixel configs. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002 Review URL: https://codereview.chromium.org/1789663002
* detach -> releaseGravatar mtklein2016-03-16
| | | | | | | | | | | | | The C++ standard library uses the name "release" for the operation we call "detach". Rewriting each "detach(" to "release(" brings us a step closer to using standard library types directly (e.g. std::unique_ptr instead of SkAutoTDelete). This was a fairly blind transformation. There may have been unintentional conversions in here, but it's probably for the best to have everything uniformly say "release". BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1809733002 Review URL: https://codereview.chromium.org/1809733002
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-02 17:44:20 +0000