SK_SUPPORT_LEGACY_DIDCONCAT44
Change-Id: Ie208c245d7121fddc693a7d3c5d6866441c27433
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281864
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: Idcc598af6b3859d33b674402c973438ddfdd632b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/282038
Commit-Queue: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Having GrAtlasManager.h in GrContextPriv.h was needlessly propagating dependence on that header.
Change-Id: Idf5836f1e217ecd2da91f751b488a63a884c02ce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281739
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
bit_clear is at least useful as a special case for select(),
which helps with code readability.
Add is_NaN() and use these all together in sweep gradient.
Change-Id: I57a54f8956f85e0db0662b33f8446b8dc7342d8d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281685
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
bit_clear() is just another bit_and(),
and bytes() is a way of expression pshufb
that we never really use (yet).
Can always add them back later, but there's
some extra complexity to think about for each
that I'd like to not think about now:
- common sub-expression elimination between bit_and and bit_clear
- large constant management JIT'ing bytes
Change-Id: I3a54afa963231fec1d5de949acc647e3430ed0d8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281557
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is a reland of d84b691950
Original change's description:
> Reland "Use glDraw.*BaseInstance calls to avoid deferred buffer binding"
>
> This is a reland of e8c963d474
>
> Original change's description:
> > Use glDraw.*BaseInstance calls to avoid deferred buffer binding
> >
> > Change-Id: I968dab317673051acc65f87ea76a0d657d89b3d2
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279538
> > Commit-Queue: Chris Dalton <csmartdalton@google.com>
> > Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> > Reviewed-by: Brian Salomon <bsalomon@google.com>
>
> Change-Id: I79b2d23e5e66d47214898a9068079b6fe2269599
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280806
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I9240c5cc6e58ce196be393c649bbdd86560602f0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281077
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Change-Id: I2d19c4f0ff1439dcd923a3064eb3ba78432a5113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281043
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This is a reland of e8c963d474
Original change's description:
> Use glDraw.*BaseInstance calls to avoid deferred buffer binding
>
> Change-Id: I968dab317673051acc65f87ea76a0d657d89b3d2
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279538
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I79b2d23e5e66d47214898a9068079b6fe2269599
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280806
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Bug: skia:9935
Change-Id: I4c2d70f69e30f78caca0f49629880565f178f495
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280609
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit e8c963d474.
Reason for revert: assert failures: https://logs.chromium.org/logs/skia/4b4b7fcb2ff3fe11/+/steps/dm/0/stdout
Original change's description:
> Use glDraw.*BaseInstance calls to avoid deferred buffer binding
>
> Change-Id: I968dab317673051acc65f87ea76a0d657d89b3d2
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279538
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,csmartdalton@google.com,michaelludwig@google.com
Change-Id: Ic760a56ca9d112e924baf7e833adb09b371928b0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280817
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This reverts commit e990fcc4b0.
Reason for revert: Build-Win-Clang-x86_64-Release-Shared
Original change's description:
> Enable deprecated-copy-dtor warning.
>
> In C++11 a user declared destructor still requires the compiler to
> implicitly default the copy constructor and copy assignment operator,
> but this is deprecated. Note that a user declared destructor suppresses
> the move constructor and move assignment operator; a user declared
> destructor exists if any '~Foo' method declaration appears inside
> 'class Foo' (even if defaulted); if the copy and move operations are the
> same then copy operations that take 'const Foo&' will do fine double
> duty as move operations.
>
> Clang seems to have an issue with this warning, in that it does not
> appear to distinguish between compiler defaulted and user defaulted
> destructors. As a result, it does not always warn when it should.
> There may yet be places in the code where a move operation is desired
> but may be suppressed because the implicitly defaulted moves are not
> declared because a destructor has been declared.
>
> This wraps dawn and shaderc configs in 'third_party' so that their
> headers will be included through '-isystem' in order to avoid the
> warnings generated by including their headers.
>
> Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,bungeman@google.com
Change-Id: Icd6a2487637d21fcf7c4c7ab7cba7a8adfda5afd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280836
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
In C++11 a user declared destructor still requires the compiler to
implicitly default the copy constructor and copy assignment operator,
but this is deprecated. Note that a user declared destructor suppresses
the move constructor and move assignment operator; a user declared
destructor exists if any '~Foo' method declaration appears inside
'class Foo' (even if defaulted); if the copy and move operations are the
same then copy operations that take 'const Foo&' will do fine double
duty as move operations.
Clang seems to have an issue with this warning, in that it does not
appear to distinguish between compiler defaulted and user defaulted
destructors. As a result, it does not always warn when it should.
There may yet be places in the code where a move operation is desired
but may be suppressed because the implicitly defaulted moves are not
declared because a destructor has been declared.
This wraps dawn and shaderc configs in 'third_party' so that their
headers will be included through '-isystem' in order to avoid the
warnings generated by including their headers.
Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Change-Id: I968dab317673051acc65f87ea76a0d657d89b3d2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279538
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
It was too easy to get into circular include chains. Added static
asserts to ensure we keep our quad AA flags in sync. Also, IWYU.
Change-Id: I01aefa264aa56420ab5a46a8ecd9e63c021c79ab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280405
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Add Dawn's dependencies shaderc and glslang, and roll SPIRV. Update the
BUILD.gn files to match upstream changes.
Bug: skia:9939, chromium:1064563
Change-Id: Ie9720806efe823312da10f7911688f12cad0713e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278770
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Weston Tracey <westont@google.com>
Adds the ANGLE extension to our list of options for
glDraw*BaseInstance.
Removes glDrawElementsInstancedBaseInstance since this method is not
supported by the ANGLE extension.
Change-Id: Ifd25324feeaad55a4d141b5064bcd8e059948ef7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280388
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This doesn't usually come up because third_party/ is mostly
only C code and clang-tidy only runs on C++ code, but it's
starting to matter as we roll in Dawn.
Change-Id: I52c64cd55281989dad837d6573c38e8b380861a3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280329
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
In particular, X.h has "#define None 0L".
Change-Id: I25f0becc9debd2d18a1735c7f573c7b1ca2b4c8a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279406
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Ambiguity has come up re: what "tessellation" means in Ganesh. I
believe that, in the context of a graphics library, "tessellation"
should refer to the hardware pipeline feature of submitting patches
and tessellating them on the GPU. This CL therefore renames classes
that triangulate things on the CPU to call it "triangulation".
Change-Id: Ic8515ea6a33000f1b638a852d5122bc9bd6b38f2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279236
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Updated to use sentinel GL context even when GL backend is not built.
This reverts commit 1171d314ef.
Change-Id: Ia94bbe4865ddd4e898446c13886877c539f0eb0b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277976
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
We haven't tested this in a while. Use the Metal backend instead.
Change-Id: Ic06bf4faff99950bd24e41bdea03962db99cfeee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277612
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This is a reland of 1c3bea4593
Original change's description:
> Set up eGPU/discrete support for MacOS.
>
> Pulled out of https://skia-review.googlesource.com/c/skia/+/271319.
>
> For Metal, will default to an eGPU or discrete GPU if one is available.
> For GL, will attempt to use a Radeon eGPU, and will fallback
> if one can't be found.
>
> Change-Id: I0a1efb3afca612ac75be56f633d811dda68f9d10
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277516
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: I1f9dcbf82465533ae8bce96b5cc73a7c627071a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277696
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This CL is interesting bc the AAHairlineOp is the first one that requires multiple programInfos.
Correspondingly, it is also the first one that shares a pipeline between said multiple programInfos.
Bug: skia:9455
Change-Id: I2369abbdeaf4eac2bc9547ad36631beba29bd641
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277203
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 1c3bea4593.
Reason for revert: breaking ios build
Original change's description:
> Set up eGPU/discrete support for MacOS.
>
> Pulled out of https://skia-review.googlesource.com/c/skia/+/271319.
>
> For Metal, will default to an eGPU or discrete GPU if one is available.
> For GL, will attempt to use a Radeon eGPU, and will fallback
> if one can't be found.
>
> Change-Id: I0a1efb3afca612ac75be56f633d811dda68f9d10
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277516
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Jim Van Verth <jvanverth@google.com>
TBR=egdaniel@google.com,jvanverth@google.com,bsalomon@google.com
Change-Id: I84c64793cc305a415f54ff0496d4ec410a94687f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277579
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Pulled out of https://skia-review.googlesource.com/c/skia/+/271319.
For Metal, will default to an eGPU or discrete GPU if one is available.
For GL, will attempt to use a Radeon eGPU, and will fallback
if one can't be found.
Change-Id: I0a1efb3afca612ac75be56f633d811dda68f9d10
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277516
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Everyone is responsible to set up their own scissor and textures now.
Change-Id: Ic3547f00c0e7908409631951de4b7237b9bce23b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277177
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Add a version tag at the start, reject any cache blobs without it
Bug: chromium:1062018
Change-Id: I18bb668e6b836e1247640e9286a69a3e745babfd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277376
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The biggest mismatch between these and SkTHash{Map,Set,Table}
is the old ones provide Iter and ConstIter, the new ones foreach().
This CL,
- adds foreach() methods to the old types,
- replaces all uses of ConstIter with foreach(),
- replaces most uses of Iter with foreach(),
I'm leaving one spot using Iter to walk the table and remove its
elements for its own CL... it'll be a little more complicated to get
that right.
From there it should be straightforward to turn SkTDynamicHash
into a thin wrapper over an SkTHashTable.
Bugs: skia:9703
Change-Id: Ia6ba87c35b89585c42b5b9f118f4cbf3abd04f0d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277098
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
'$' lets you see what the serialized version looks like. Helps diagnose
failures in dm/fm
Change-Id: I0c3acdeb6e7f170f5caeba1c0516b449eb7402ea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276756
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
This CL moves the boiler-plate implementation of onPrePrepareDraws up to GrMeshDrawOp. This, unfortunately, required the addition of a 'programInfo' virtual but that may go away in the future.
The only GrMeshDrawOp-derived classes left are:
AAHairlineOp - which has 3 programInfos
AAFlatteningConvexPathOp - which has >=1 mesh (but just 1 programInfo)
GrAtlasTextOp - which has inline uploads
SmallPathOp - which, maybe, has inline uploads
TextureOp - which has chaining
Bug: skia:9455
Change-Id: Id10f70e764054134751545ad38b99f0a0778de76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276642
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
SkCanvas keeps its non-exotic drawBitmap calls for now but they
immediately wrap the bitmap in SkImage::MakeFromBitmap. This will
add a copy for mutable bitmaps, but this can be worked around by using
images directly (preferred), or marking the bitmap as immutable. In
practice, mutable bitmaps do not seem to be widely used so this is
deemed acceptable for now.
Several GMs are updated to mark the bitmaps as immutable in order to
avoid pixel churn in how CPU vs. GPU mipmaps are generated. As we move
towards explicit mipmap generation, this distinction will become less
critical, so I'm just avoiding it for now. See skbug.com/9337 for mipmap
proposal. The image diffs encountered in this CL directly related to
generating mipmaps for bitmaps already cached on the GPU vs. not on the
GPU yet.
It was decided to copy if mutable vs. never copying the bitmap because
it preserves the image guarantees the devices and canvas' rely on,
and imposing the need to inspect an image for mutability is undesired.
Bug: skia:10037, skia:9337
Change-Id: If152e6cae1e155ccf6bd2cd755895f3c7a0135a5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276004
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
