Still requires SkSL support before it will work.
The main changes here involve support for uniforms in the geometry shader.
We use the same buffer for vertex and geometry shader stages. These
uniforms are not expected to be updated as often as frag data so we keep them
separate to avoid larger buffer uploads to the gpu.
BUG=skia:
Change-Id: I10b631c24071b6ffa258907a02a009ec6c8accd0
Reviewed-on: https://skia-review.googlesource.com/8413
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
And, some file cleanup.
Change-Id: I804db924bce3b5834f6cda481315dd2da38df5ca
Reviewed-on: https://skia-review.googlesource.com/15226
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Also enables mouse support in Viewer.
Change-Id: Iaed08d42a64f591f0cd9b24684b3aee43404ed94
Reviewed-on: https://skia-review.googlesource.com/15313
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit cef018896e.
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>
- 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>
I just landed a CL that changed dithering enough that it's worth seeing
if this test passes again.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Android-Clang-PixelC-CPU-TegraX1-arm64-Release-Android,Test-Android-Clang-Nexus10-CPU-Exynos5250-arm-Release-Android
Change-Id: I1dfd27fdc7d8646e0008b667617383c08c7abd5a
Reviewed-on: https://skia-review.googlesource.com/15315
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
- mention 2017
- describe 32-bit builds a bit more
Change-Id: I386c51bcf4863f91db2eade01bad1e54c1049e6c
Reviewed-on: https://skia-review.googlesource.com/15314
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
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>
for geometric shadows.
This matches the analytic shadow approach better, and
is color space invariant.
Also includes cleanup in SampleAndroidShadows.
Bug: skia:6546
Change-Id: I7a7cd060420dae741f967334c8b19542a14f0bcf
Reviewed-on: https://skia-review.googlesource.com/15228
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
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>
This handles negative values in the spot translation, and produces
a tight fit for rrects and circles.
Change-Id: Id2536347dca98f06f57b31518390037b86fd8a9e
Reviewed-on: https://skia-review.googlesource.com/15248
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Basically a GrTextureProxified clone of GrGpuResourceRef
Change-Id: I8772550bb867ef2cf2d53efef0a0346bb7c90eb6
Reviewed-on: https://skia-review.googlesource.com/15221
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Completes implementation for lazy and raster images. gpu is
still a TODO.
Bug: skia:6553
Change-Id: I898e4464ffc91442c7f98669f1203dd5c203621b
Reviewed-on: https://skia-review.googlesource.com/15307
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
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>
This reverts commit 9ad0531a18.
Reason for revert: Does not handle transfer fn behavior.
Original change's description:
> Add SkImage::makeColorSpace() with correct transfer fn behavior
>
> Completes implementation for lazy and raster images. gpu is
> still a TODO.
>
> Bug: skia:6553
> Change-Id: I04eea5c4fb53c50c0406c2e6b6778b0e21fd85f8
> Reviewed-on: https://skia-review.googlesource.com/14403
> Commit-Queue: Matt Sarett <msarett@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
>
TBR=mtklein@google.com,msarett@google.com,brianosman@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I3830321aea7d0dc5ab38a40f3318bb53a41df383
Reviewed-on: https://skia-review.googlesource.com/15306
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
If a previously-enclosing edge coincides exactly with the current
vertex, there are no two adjacent edges which enclose the vertex.
Since find_enclosing_edges() ensures that the left enclosing edge
is to the left of the vertex, the fix is to split the right
enclosing edge on the current vertex and restart intersection
tests.
Bug: 716720
Change-Id: Id26c5b92a6d6139f348e99554638cded37e81a8e
Reviewed-on: https://skia-review.googlesource.com/15261
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Completes implementation for lazy and raster images. gpu is
still a TODO.
Bug: skia:6553
Change-Id: I04eea5c4fb53c50c0406c2e6b6778b0e21fd85f8
Reviewed-on: https://skia-review.googlesource.com/14403
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This reverts commit a4f3e14d89.
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>
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>
This reverts commit ff574e0eb7.
Reason for revert: needs a merge
Original change's description:
> Add a new non-AA rect op that does not inherit from GrLegacyMeshDrawOp.
>
> This uses a new helper class, GrSimpleMeshDrawOpHelper, which it uses to fullfill the GrMeshDrawOp contract and to construct its GrPipline when flushed. The helper is intended to be used such that the op only stores a GrProcessorSet if it is constructed with a "nontrivial" GrPaint. "Trivial" currently means no fragment processors and src-over blending. The helper allows the op subclass to specify whether it supports stenciling via a template parameter. The helper class is initially intended to be used for ops that don't have per-vertex colors and construct a single GrPipeline at flush time, though perhaps this can be relaxed in future changes.
>
> On the microbenchmark "rotated_rects_bw_same_transparent_srcover" this produces a 18-20% reduction in time on my Z840 running Linux and 33% on my 2010 MacPro.
>
> Bug: skia:
> Change-Id: I9f655827a70bee585b0b0e1255371ffd995a0b80
> Reviewed-on: https://skia-review.googlesource.com/14604
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
>
TBR=bsalomon@google.com,robertphillips@google.com,brianosman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2893d6ff7c183a18f7d0ba82818701b80b681eb0
Reviewed-on: https://skia-review.googlesource.com/15280
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This uses a new helper class, GrSimpleMeshDrawOpHelper, which it uses to fullfill the GrMeshDrawOp contract and to construct its GrPipline when flushed. The helper is intended to be used such that the op only stores a GrProcessorSet if it is constructed with a "nontrivial" GrPaint. "Trivial" currently means no fragment processors and src-over blending. The helper allows the op subclass to specify whether it supports stenciling via a template parameter. The helper class is initially intended to be used for ops that don't have per-vertex colors and construct a single GrPipeline at flush time, though perhaps this can be relaxed in future changes.
On the microbenchmark "rotated_rects_bw_same_transparent_srcover" this produces a 18-20% reduction in time on my Z840 running Linux and 33% on my 2010 MacPro.
Bug: skia:
Change-Id: I9f655827a70bee585b0b0e1255371ffd995a0b80
Reviewed-on: https://skia-review.googlesource.com/14604
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We suspect that having SkTDPQueue inherit from SkNoncopyable is
what's causing this error:
third_party/skia/HEAD/src/gpu/GrResourceCache.h:44:7: error: 'GrResourceCache' declared with greater visibility than the type of its field 'GrResourceCache::fPurgeableQueue' [-Werror=attributes]
class GrResourceCache {
^
Change-Id: Idc737aa64f5cb159edbe59e8baf70d711f7e07d9
Reviewed-on: https://skia-review.googlesource.com/15243
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
We're no longer necessarily going to get exact results as we go along.
Lots of little things like dither, FMA, whether we're using the full
precision pipeline or the old paths, etc.
Change-Id: Iacba1820e79cd1e380d3af7861d9678ca7b93ad8
Reviewed-on: https://skia-review.googlesource.com/15246
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Converts GrMesh to a struct and changes the names/semantics of its
fields to be more inline with their GL counterparts. Also renames the
"instancing" feature to "pattern", to avoid ambiguity with hardware
instancing.
Bug: skia:
Change-Id: Ia0999d4f9c83b5dd31f81b9bf4f36ed9abd26286
Reviewed-on: https://skia-review.googlesource.com/15157
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
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>
This is a prototype. I have remove the tiling,
but maybe I should add it back in.
I thinking about factoring out the common code with
linear gradient in its own CL.
I think radial gradient will be very close to this.
Change-Id: I1dfcb4f944138ee623afdf10b2a8befde797c604
Reviewed-on: https://skia-review.googlesource.com/13766
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Herb Derby <herb@google.com>
