This turns out to be mostly deleting dead debugging code.
Change-Id: I4969ea380e6125e8b557d430c6720edc0a337a79
Reviewed-on: https://skia-review.googlesource.com/c/174284
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Ia400db2b73a8061668e62f8e961538a060b216a1
Reviewed-on: https://skia-review.googlesource.com/c/174282
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I6eb4469df0315283f96631ff6023170fa80aaa8a
Reviewed-on: https://skia-review.googlesource.com/c/174281
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Whatever nonsense SkPicture::uniqueID() was doing, it doesn't
need to do it. It can just get its unique ID normally.
I've ported SkEventTracer in the straightforward way.
Change-Id: I103e7e05258ad49e1e3f333fc907f039cef3f8c9
Reviewed-on: https://skia-review.googlesource.com/c/174280
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
- Replace sk_memory_order with std::memory_order.
- Remove SkAtomic<T>.
SkPath was the only user of SkAtomic<T>, for its fConvexity and
fFirstDirection fields. I've replaced them with std::atomic types, and
funneled access to them through methods that enforce the relaxed memory
order like SkAtomic<T> did.
For fConvexity, we can use the exisiting setConvexity() and
getConvexityOrUnknown() methods, adding a private const setConvexity()
to mutate convexity from const methods. For fFirstDirection I've added
private setFirstDirection() and getFirstDirection() methods.
Removing SkAtomic<T> means SkAtomics.h no longer needs SkNoncopyable.h.
I've had to update a bunch of other headers that were depending on
transitive inclusion.
Change-Id: Ib238be71a121519db6e970a9a8955834e1298c87
Reviewed-on: https://skia-review.googlesource.com/c/174220
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
In theory, a convex shape is still convex if transformed by an affine
matrix. However, SkPath segments are specified using floats, and attributes
like collinearity can break under some transforms due to finite precision.
Computing convexity is non-trivial, so there is value in SkPath caching this
calculation. Convexity is useful, as both the CPU and GPU backends can draw
convex shapes faster than non-convex.
To balance these two (fragile float math and value of caching convexity),
this CL invalidates this cached state if the transform could change convexity.
In the general case, it is assumed that convexity could change. Special cases
where it is safe to keep the cached state after transform are:
- identity transform
- scale/translate transform if the path is known to be axis-aligned
All other combinations invalidate the cached state, forcing it to be
recomputed.
"axis-aligned" means the segments in the path are all axis-aligned, horizontal
or vertical (e.g. a rect or rrect)
Bug: 899689
Change-Id: I1381273eaff61d6b7134ae94b4f251c69991081a
Reviewed-on: https://skia-review.googlesource.com/c/173226
Commit-Queue: Ravi Mistry <rmistry@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Change-Id: I4232d23e0c2dfe46695e948c46f2745c8e7e555c
Reviewed-on: https://skia-review.googlesource.com/c/172945
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This fixes a crash in skiaserve when running in GPU mode.
Remove GR_AUDIT_TRAIL_OP_RESULT_NEW. This macro doesn't do anything and
is non-trivial to know when to call if a new op gets chained.
Change-Id: Ic2a9c09e3d15541a566534654b2393cb740fa302
Reviewed-on: https://skia-review.googlesource.com/c/172864
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:
Change-Id: I2d166ed6c1cb1c13a91526e2f0340623e0436003
Reviewed-on: https://skia-review.googlesource.com/c/171782
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: Ie681369ef4b1d3d43c326da684afde9ce6d08486
Reviewed-on: https://skia-review.googlesource.com/c/171726
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
GrVertexColor stores either kind of color, and GrVertexWriter does the
right thing. SkColor4fPrepForDst helps to automate the conversion and
pinning. This ensures that colors are already pinned if the device has
no support for half-floats. This way, ops never need to worry about caps,
they can just check if all colors they're batching are normalized.
Bug: skia:
Change-Id: Ie0c15d3b16c6fc93a7f11d284029d77d482a6283
Reviewed-on: https://skia-review.googlesource.com/c/171725
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Used in upcoming changes to decide between byte and half-float
vertex attributes for Ops that store paint colors in vertices.
Bug: skia:
Change-Id: Idbcc801b15c1d99c604fc393cde18032ae5702c6
Reviewed-on: https://skia-review.googlesource.com/c/170262
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This is going to be faster, and it's the last usage of GrColorMul
Bug: skia:
Change-Id: I2ecbed55ec401792f8d8f8ab9dc91a14182094b4
Reviewed-on: https://skia-review.googlesource.com/c/171520
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
They're only specialized up to SSE2 or NEON,
both of which are typical baseline builds now.
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If2b2bbd5b002038c68c0064ee78d75911a33b988
Reviewed-on: https://skia-review.googlesource.com/c/170064
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 51b1c12bbc.
Reason for revert: reverting till flutter gets to 1.1 to fix build issues.
Original change's description:
> Have a GrBackendFormat be stored on gpu proxies.
>
> Bug: skia:
> Change-Id: Iaf1fb24ab29a61d44e5fa59a5e0867ed02dcda90
> Reviewed-on: https://skia-review.googlesource.com/c/168021
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Greg Daniel <egdaniel@google.com>
TBR=egdaniel@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: I574fdc084ef5994596c51fb0d60423b5dc01b885
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:903701 chromium:903756
Reviewed-on: https://skia-review.googlesource.com/c/169835
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Bug: skia:
Change-Id: Iaf1fb24ab29a61d44e5fa59a5e0867ed02dcda90
Reviewed-on: https://skia-review.googlesource.com/c/168021
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Change-Id: I9ba1caa4862bdf9ffc9c0e637bd69cce91fd8468
Reviewed-on: https://skia-review.googlesource.com/c/168740
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is a reland of 166dbd3135
Since last attempt,
- update SkPath::Direction docs
- kIllegal is not an advanced blend mode
Original change's description:
> make enum santizer fatal
>
> This enum sanitizer checks that all the values of the enum we use fall
> within the range of the enumerated values.
>
> The main thing this helps point out is that the size of enum types in
> C++ need only be large enough to hold the largest declared value; larger
> values are undefined. In practice, most enums are implemented as ints
> for compatibility with C, so while this hasn't pointed out anything
> egregiously broken, the sanitizer has found a couple possibly dangerous
> situations in our codebase.
>
> For most types using values outside the enum range, we can just
> explicitly size them to int. This makes their de facto size de jure.
>
> But we need to actually make GrBlendEquation and GrBlendCoeff not store
> values outside their enumerated range. They're packed into bitfields
> that really can't represent those (negative) values. So for these I've
> added new kIllegal values to the enums, forcing us to deal with our
> once-silent illegal values a bit more explicitly.
>
> Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
> Reviewed-on: https://skia-review.googlesource.com/c/168484
> Reviewed-by: Brian Osman <brianosman@google.com>
Cq-Include-Trybots: skia.primary:Housekeeper-PerCommit-Bookmaker,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-All-Android
Change-Id: Id93b80bbeae11872542c9b76715e3c3cb10609fd
Reviewed-on: https://skia-review.googlesource.com/c/168582
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 166dbd3135.
Reason for revert: illegal is not advanced, docs
Original change's description:
> make enum santizer fatal
>
> This enum sanitizer checks that all the values of the enum we use fall
> within the range of the enumerated values.
>
> The main thing this helps point out is that the size of enum types in
> C++ need only be large enough to hold the largest declared value; larger
> values are undefined. In practice, most enums are implemented as ints
> for compatibility with C, so while this hasn't pointed out anything
> egregiously broken, the sanitizer has found a couple possibly dangerous
> situations in our codebase.
>
> For most types using values outside the enum range, we can just
> explicitly size them to int. This makes their de facto size de jure.
>
> But we need to actually make GrBlendEquation and GrBlendCoeff not store
> values outside their enumerated range. They're packed into bitfields
> that really can't represent those (negative) values. So for these I've
> added new kIllegal values to the enums, forcing us to deal with our
> once-silent illegal values a bit more explicitly.
>
> Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
> Reviewed-on: https://skia-review.googlesource.com/c/168484
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@chromium.org,mtklein@google.com,brianosman@google.com
Change-Id: I691c08092340a6273e442c0f098b844f7d0363ba
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/168581
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This enum sanitizer checks that all the values of the enum we use fall
within the range of the enumerated values.
The main thing this helps point out is that the size of enum types in
C++ need only be large enough to hold the largest declared value; larger
values are undefined. In practice, most enums are implemented as ints
for compatibility with C, so while this hasn't pointed out anything
egregiously broken, the sanitizer has found a couple possibly dangerous
situations in our codebase.
For most types using values outside the enum range, we can just
explicitly size them to int. This makes their de facto size de jure.
But we need to actually make GrBlendEquation and GrBlendCoeff not store
values outside their enumerated range. They're packed into bitfields
that really can't represent those (negative) values. So for these I've
added new kIllegal values to the enums, forcing us to deal with our
once-silent illegal values a bit more explicitly.
Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
Reviewed-on: https://skia-review.googlesource.com/c/168484
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I395395b1cd81a1d45ca779b2273015c8ed9fb882
Reviewed-on: https://skia-review.googlesource.com/c/168361
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 5a4f2a341a.
Bug: skia:
Change-Id: I706009343dc1976311a88d57800a140efd776861
Reviewed-on: https://skia-review.googlesource.com/c/168363
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 52065473ee.
Reason for revert: Typo messed up LCD blending
Original change's description:
> Use float colors for blend constant
>
> Bug: skia:
> Change-Id: Ie2a4b341a5e7762c3e8031fbd0f0d8b1ebae27f1
> Reviewed-on: https://skia-review.googlesource.com/c/168268
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=egdaniel@google.com,mtklein@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: Ieaad5724099e18727296ce312d728a1a9ed45c4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/c/168362
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: Ie2a4b341a5e7762c3e8031fbd0f0d8b1ebae27f1
Reviewed-on: https://skia-review.googlesource.com/c/168268
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: I5386e27edbcf39233880d869841a6632ecb9416c
Reviewed-on: https://skia-review.googlesource.com/c/168261
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: I942e46c2b680714cdd10f7393c6a4d206df645a8
Reviewed-on: https://skia-review.googlesource.com/c/167394
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
SkRefCntBase is an implementation detail of SkRefCnt, so let's not
mention it in SkContext_Compute.h. While I'm here, I notice SkNVRefCnt
would work fine too.
No one else calls internal_dispose_restore_refcnt_to_1(), so we can
inline it. While here, I notice it's resetting the ref count to 1 even
in release builds. I'm not sure if that is/can be optimized away, but
in any case I think we can wrap with #ifdef SK_DEBUG, if only to make it
clear that it's only there to support the assert in the destructor.
I've removed validate(). Most of the places it's called read pretty
weird, and I think suggest some sort of class-specific validation than
just checking that we're holding a ref. SkWeakRefCnt::validate() isn't
called anywhere.
There were few users of getRefCnt() outside SkRefCnt itself, so I
removed the rest and made it private.
I've added a few this-> to self calls while at it.
Change-Id: I98be06677a6e8b8e66f44cbb17d14e38b0f39d38
Reviewed-on: https://skia-review.googlesource.com/c/167160
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
- Mechanical replacement of GrColor4h (used throughout Ops) with
SkPMColor4f.
- API adaptation (to/FromGrColor -> to/From_BytesRGBA).
- Complete removal of FromFloats (source was already SkPMColor4f),
and toFloats (setting uniforms can directly access .vec()).
Bug: skia:
Change-Id: I37eece1fa7ed2545dc6843e840d4cc3c60f19747
Reviewed-on: https://skia-review.googlesource.com/c/166620
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The Windows header definitions of NAN and INFINITY involve overflowing
math, making clang treat them as not being constexpr. Now they're
constexpr everywhere.
Bug: skia:
Change-Id: I84c05aae2952a152fed4eceb55cd2680d6fd5b05
Reviewed-on: https://skia-review.googlesource.com/c/166840
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This function was misleading because GrRenderTargetOpList::forwardCombine
can leave holes in the array which were still counted.
It would be harder to track this in op chaining redux.
Change-Id: Ib9619839012cb7dd2d0e4ccac31a231787f90f2d
Reviewed-on: https://skia-review.googlesource.com/c/166442
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This is a test CL to measure perf impact on the bots
Bug: skia:
Change-Id: I8aae0ac1373921d4d1b5f92e1f6b2318e66f0032
Reviewed-on: https://skia-review.googlesource.com/c/166283
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 0fb1ee98cf.
Reason for revert: looks like this increased size by ~8K.
Original change's description:
> replace SkNVRefCnt with SkRefCnt
>
> SkNVRefCnt trades a small amount of code size (vtable) and runtime
> (vptr) memory usage for a larger amount of code size (templating). It
> was written back in a time when all we were really thinking about was
> runtime memory usage, so I'm curious to see where performance, code
> size, and memory usage all move if it's removed.
>
> Looking at the types I've changed here, my guess is that performance and
> memory usage will be basically unchanged, and that code size will drop a
> bit. Nothing else it's nicer to have only one ref-counting base class.
>
> Change-Id: I7d56a2b9e2b9fb000ff97792159ea1ff4f5e6f13
> Reviewed-on: https://skia-review.googlesource.com/c/166203
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,bsalomon@google.com,mtklein@chromium.org
Change-Id: Ibcfcc4b523c466a535bea5ffa30d0fe2574c5bd7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/166360
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
SkNVRefCnt trades a small amount of code size (vtable) and runtime
(vptr) memory usage for a larger amount of code size (templating). It
was written back in a time when all we were really thinking about was
runtime memory usage, so I'm curious to see where performance, code
size, and memory usage all move if it's removed.
Looking at the types I've changed here, my guess is that performance and
memory usage will be basically unchanged, and that code size will drop a
bit. Nothing else it's nicer to have only one ref-counting base class.
Change-Id: I7d56a2b9e2b9fb000ff97792159ea1ff4f5e6f13
Reviewed-on: https://skia-review.googlesource.com/c/166203
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We still degrade to bytes when creating vertices (tagged TODO4F).
Note: Guarded for Chrome (by making GrColor4h a wrapper around
GrColor).
Bug: skia:
Change-Id: Id8a1d9eec7978d52b059cd9952666bc1217ee073
Reviewed-on: https://skia-review.googlesource.com/c/165527
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
GrPremulColor is only use in test code, and is redundant
Bug: skia:
Change-Id: I4a22941d28cbec3eb203bca393cfeccffe04e053
Reviewed-on: https://skia-review.googlesource.com/c/165524
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
To keep things sane, move SkNx and SkHalf to include/private
Bug: skia:
Change-Id: Iaee8c3f92a2720bf97583c3f326486d4ce462e8b
Reviewed-on: https://skia-review.googlesource.com/c/165344
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
We're going to use half-floats, which are far more future-proof.
Bug: skia:
Change-Id: I6e098017381256d6e750ac546c353072802282cb
Reviewed-on: https://skia-review.googlesource.com/c/165522
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I91b9816aae74726762c123d9f3454c5961382b7b
Reviewed-on: https://skia-review.googlesource.com/c/164680
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
All uses have been converted to SkPMColor4f (or similar).
Bug: skia:
Change-Id: I220bd5eaf6c35b17321c1e8bc92ace7ff92908c4
Reviewed-on: https://skia-review.googlesource.com/c/162749
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This adds SkPMColor4f conversions to/from RGBA bytes (ie GrColor).
I had previously made some free functions that did the same thing.
I'm ambivalent about which option is nicer, but wanted to have one
method, so I converted everything to use the new versions.
Bug: skia:
Change-Id: I4194c44b5bd12228075fd1932a14cf31c8d6a3c1
Reviewed-on: https://skia-review.googlesource.com/c/162560
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change the behavior from allocating only the memory needed for T.
to an exponential growth starting at 1024.
Change-Id: Id37e0fb9e269feebf669ebc73f9e26dcd0589452
Reviewed-on: https://skia-review.googlesource.com/c/162102
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
are not recyclable.
Change-Id: I5ff9c48b3d7b37531a3f052bd5188a8afcacf3cb
Reviewed-on: https://skia-review.googlesource.com/c/161860
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 0a0304c426.
Reason for revert: Breaking metal
Original change's description:
> Add experimental API to draw a set of SkImages in one SkCanvas call.
>
> The client provides a src and dst rect for each image as well as
> a bitfield that indicates whether each edge of the image should be
> antialiased. This per-edge AA is useful for tiled compositors.
>
> Rather than take a full SkPaint this API only takes an alpha, a filter
> quality (which is pinned to kLow), and a blend mode. This is a likely
> point of future evolution.
>
> Currently the API is only fully implemented for kSrcOver on the GPU
> backend. With other blend modes or on other backends AA will be ignored
> for images that do not have all four edge AA flags set.
>
> BUG: skia:8444
>
> Change-Id: I143998dda8ad6a25f64e18cd600392ba553030ac
> Reviewed-on: https://skia-review.googlesource.com/c/159062
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,brianosman@google.com,reed@google.com
Change-Id: I815baaeee5de9c6722cf2b9d071a8e2f7c1b6a96
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/161622
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The client provides a src and dst rect for each image as well as
a bitfield that indicates whether each edge of the image should be
antialiased. This per-edge AA is useful for tiled compositors.
Rather than take a full SkPaint this API only takes an alpha, a filter
quality (which is pinned to kLow), and a blend mode. This is a likely
point of future evolution.
Currently the API is only fully implemented for kSrcOver on the GPU
backend. With other blend modes or on other backends AA will be ignored
for images that do not have all four edge AA flags set.
BUG: skia:8444
Change-Id: I143998dda8ad6a25f64e18cd600392ba553030ac
Reviewed-on: https://skia-review.googlesource.com/c/159062
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
For destinations, Premul vs. Unpremul is actually meaningful
for these color types - it determines whether or not we divide
through by alpha after blending. Opaqueness ought to just be
a performance hint, and only for sources.
Bug: skia:
Change-Id: I801a64316ec9c92642982cd2096f8bec9a7855f3
Reviewed-on: https://skia-review.googlesource.com/c/161423
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 9835dd51b3.
Reason for revert: Chrome unit tests failing?
Original change's description:
> Fix image info checking for always-opaque color types
>
> The old code overlooked 101010x and 888x. The GPU code for
> readPixels tried to enfore this, but incorrectly, and the
> writePixels code missed it entirely.
>
> Bug: skia:
> Change-Id: Ib69473703f2ae7604d4b21ec6728b7d764becd9a
> Reviewed-on: https://skia-review.googlesource.com/c/161148
> Commit-Queue: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
> Auto-Submit: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: I360375f2bf21576db914f5e177ac56e398ca7023
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/c/161380
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The old code overlooked 101010x and 888x. The GPU code for
readPixels tried to enfore this, but incorrectly, and the
writePixels code missed it entirely.
Bug: skia:
Change-Id: Ib69473703f2ae7604d4b21ec6728b7d764becd9a
Reviewed-on: https://skia-review.googlesource.com/c/161148
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
This reverts commit c0a74a1f76.
Reason for revert: made flutter 7K bigger for no real gain.
Original change's description:
> SkTArray: clean up, no change to behaviour
>
> Change-Id: I15883216995a0ffe1ee1b183291cf0ea5867f613
> Reviewed-on: https://skia-review.googlesource.com/c/161042
> Commit-Queue: Hal Canary <halcanary@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,halcanary@google.com
Change-Id: I10756cd384c352ede68636a08e7cdd83c6833e4f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/161260
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I15883216995a0ffe1ee1b183291cf0ea5867f613
Reviewed-on: https://skia-review.googlesource.com/c/161042
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This is split out of: https://skia-review.googlesource.com/c/skia/+/143113 (Reduce arbitrary opList splitting when sorting (take 3)).
It needs to be behind a context option because, without mini-flushes, it can cause OOM on smaller devices (e.g., Nexus7 and AndroidOne).
Change-Id: Icde3302bd033a9c4634bb0ca97c950456e73db7c
Reviewed-on: https://skia-review.googlesource.com/c/160763
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Convert GrConstColorProcessor to store SkPMColor4f
Bug: skia:
Change-Id: I6c505856653a02e576ae11fca59dc307545437f7
Reviewed-on: https://skia-review.googlesource.com/c/159152
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Outsetting in perspective case outsets the original homogeneous quad
points rather than the homogenized 2d points in order to avoid seaming
issues along shared edges.
Currently there is no way to trigger this from the public API and it
is tested by directly accessing GrRenderTargetContext from the added gm.
Change-Id: I24e0d53cc5821c8c8be07c23aca5bfafb4935c33
Reviewed-on: https://skia-review.googlesource.com/157600
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
We'd really like to converge on SkRGBA4f everywhere. This CL continues
to store GrColor4f in the GPU backend, but changes the constantColor
optimization logic to use SkPMColor4f.
GrColor[4f] have "unknown" alpha type, but in this context, they are
nearly always premul, so let's take advantage of our SkRGBA4f type
safety. We lose some of the semantic benefits and helpers that are
present in GrColor4f (OpaqueWhite, TransparentBlack).
The biggest thing that would probably help is a direct path to/from
bytes (GrColor).
Bug: skia:
Change-Id: Ic0838ad3f95d207163b3af51e5f5cf6f499c2047
Reviewed-on: https://skia-review.googlesource.com/157840
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The main two CLs calved off (and landed independently) from this CL are:
https://skia-review.googlesource.com/c/skia/+/156761 (Add SkImage_Gpu::MakePromiseYUVATexture)
-- adds internal place holder for YUVA promise images (only returns Y channel)
https://skia-review.googlesource.com/c/skia/+/156140 (Add SkImage_Base API to access planar data)
-- adds ability to grab planes for testing purposes (not externally visible)
Bug: skia:7903
Bug: skia:8424
Change-Id: Id0f2f84851dacc66c2c266a30cafa0b628b12eb4
Reviewed-on: https://skia-review.googlesource.com/151983
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Remove SkEncodedInfo::ICCProfile::MakeSRGB. Instead of creating
this object whenever there is no encoded color profile, just
treat null as sRGB, like skcms does.
This may help with crbug.com/887372. Regardless it simplifies the
code.
Also fix a bug where SkCodec could have passed a null
skcms_ICCProfile to skcms_ApproximatelyEqualProfiles (related
to b/116608007).
Bug: chromium:887372
Change-Id: I2374e8d8a1aed261f1291b7f6fd6c7ea662f26fd
Reviewed-on: https://skia-review.googlesource.com/157561
Auto-Submit: Leon Scroggins <scroggo@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Most functionality is shared, but this lets us get type safety.
SkColor4f = SkRGBA4f<kUnpremul>
SkPMColor4f = SkRGBA4f<kPremul>
Change-Id: I27408565dc92e722f42a185cecbf7af15d1dde3f
Reviewed-on: https://skia-review.googlesource.com/156243
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
No longer used anywhere.
Change-Id: I029d0caf1bb60ba3e77761648193c01d39c37183
Reviewed-on: https://skia-review.googlesource.com/155843
Commit-Queue: Hal Canary <halcanary@google.com>
Auto-Submit: Ben Wagner <bungeman@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Bug: skia:
Change-Id: I9a99cb28fd239371ca21b4a918e802606afe9da0
Reviewed-on: https://skia-review.googlesource.com/155840
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit 90d2d9381e.
Updated to use float in the shader (many ES2 implementations
don't support integral types as attributes).
Bug: skia:
Change-Id: I0898f1730da60ff03f8165b2f1a3ee18a7b2fec8
Reviewed-on: https://skia-review.googlesource.com/155162
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I76ab59d963cebf6cbb450e1873c3e0c63f3f2da0
Reviewed-on: https://skia-review.googlesource.com/155560
Commit-Queue: Hal Canary <halcanary@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Hal Canary <halcanary@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
PS1 reverts commit 6c8d242b14.
PS2 uses an SkMutex for thread safety.
Change-Id: I9318f92cc028844b3dc5a99a00282c2762057895
Reviewed-on: https://skia-review.googlesource.com/155060
Reviewed-by: Mike Klein <mtklein@google.com>
Make the listner list for bitmas and paths use a simple atomic
stack. This stack implementation does not have the ABA problem
because you can only pop the entire stack at once
with exchange(nullptr).
BUG=skia:8324
Change-Id: I7b0438a42c473b36cd4b0cbf236bf1692c5afab3
Reviewed-on: https://skia-review.googlesource.com/154861
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit d2ca0473f6.
Reason for revert: Various bots failing.
Original change's description:
> Add Short4 vertex attributes, and benchmark them as 4.12 colors
>
> This is likely our best widely portable option for encoding wide gamut
> colors that doesnt sacrifice too much performance. The benchmark uses
> them as we're likely to do: 4.12 fixed point, in the destination color
> space. We're using SINT vertex attributes for simplicity, so the encode
> and decode are simple multiply/divide by 4096.
>
> Bug: skia:
> Change-Id: I9b544f3e187b775d81f83dc9dd44611570ad33c2
> Reviewed-on: https://skia-review.googlesource.com/155001
> Reviewed-by: Mike Klein <mtklein@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: I921e29cf9a121c5752ec7d99a03470b5193afd4a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/154883
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is likely our best widely portable option for encoding wide gamut
colors that doesnt sacrifice too much performance. The benchmark uses
them as we're likely to do: 4.12 fixed point, in the destination color
space. We're using SINT vertex attributes for simplicity, so the encode
and decode are simple multiply/divide by 4096.
Bug: skia:
Change-Id: I9b544f3e187b775d81f83dc9dd44611570ad33c2
Reviewed-on: https://skia-review.googlesource.com/155001
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The CPU type is still specified using GrVertexAttribType.
The GPU type is specified directly using GrSLType.
kHalfX_GrVertexAttribType now really means half-float buffer
data, rather than float. (Caveat: The GL enum is only correct
with ES3/GL3 - ES2+extension needs a different value. Sigh.)
Bug: skia:
Change-Id: Ife101db68a5d4ea1ddc2f6c60fbec0c66d725c16
Reviewed-on: https://skia-review.googlesource.com/154628
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Actually takes a ref on fOwningPerOpListPaths, instead of just
asserting it continues to exist. Removes unnecessary asserts
surrounding dangling pointers.
Bug: skia:8359
Change-Id: Ie80da55510f320452bd9ee3a4b38bd59d48681a0
Reviewed-on: https://skia-review.googlesource.com/154684
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
We don't have anything drawing colors outside sRGB,
but now that we've got SkPaint::setColor4f(), that's easy.
Looks like we have lots of work to do.
Pin GrColor4f floats before converting to unsigned.
Underflowing floats would get pinned to 255 spuriously
instead of to 0. I think this fixes the failing CQ
bot, and the white square problem.
Change-Id: I866963ff026e6ab891b4c7d57decc43538000099
Reviewed-on: https://skia-review.googlesource.com/153640
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit e53de48393.
Reason for revert: Key size distribution has changed back.
Original change's description:
> increase Builder's prealloc size after colorspace change
>
> BUG=skia:
>
> Change-Id: I003dcbde7d987404ae823df6621e13664cf440a1
> Reviewed-on: https://skia-review.googlesource.com/9523
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,brianosman@google.com,reed@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: skia:
Change-Id: I506a1ec791e6d99df1836cbf3262747fbfa224a7
Reviewed-on: https://skia-review.googlesource.com/153008
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 3b347232bc.
Reason for revert: tree done gone red.
Original change's description:
> SkMath takes some functions from from SkTypes
>
> Moved to include/core/SkMath.h: Sk{Is|}Align{2|4|8|Ptr}, SkLeftShift,
> SkAbs{32|}, SkM{ax|in}32 SkTM{in|ax}, SkTClamp, SkFastMin32, SkTPin.
>
> Change-Id: Ibcc07be0fc3677731048e7cc86006e7aa493cb92
> Reviewed-on: https://skia-review.googlesource.com/133381
> Auto-Submit: Hal Canary <halcanary@google.com>
> Reviewed-by: Ben Wagner <bungeman@google.com>
> Commit-Queue: Hal Canary <halcanary@google.com>
TBR=mtklein@google.com,halcanary@google.com,bungeman@google.com,reed@google.com
Change-Id: I44073cf397e2a3a6a941a90f0aa63c6396d4c742
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/152587
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 49894f450f.
Reason for revert: Breaking a CTS test on the Android roll:
java.lang.AssertionError: expected:<67043583> but was:<50266367>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at android.graphics.cts.BitmapColorSpaceTest.verifyGetPixel(BitmapColorSpaceTest.java:301)
at android.graphics.cts.BitmapColorSpaceTest.inColorSpaceP3ToSRGB(BitmapColorSpaceTest.java:612)
Expected: 3FF00FF Actual: 2FF00FF
Original change's description:
> Reland "Switch SkCodec to use skcms" plus fixes
>
> This reverts commit 33d5394d08,
> relanding 81886e8f94 as well as
> "Fix CMYK handling in JPEG codec" (commit
> f8ae5ce20c)
>
> Add a test based on the CTS test that failed in the original commit.
> purple-displayprofile.png is the image used in the CTS test, with the
> Android license.
>
> This also adds a fix for SkAndroidCodec, ensuring that we continue to
> use a wide gamut SkColorSpace for images that do not have a numerical
> transfer function and have a wide gamut. This includes a test, with
> wide-gamut.png, which was created with Photoshop and the profile
> "sRGB_Calibrated_Homogeneous.icc" from the skcms tree.
>
> Bug: skia:6839
> Bug: skia:8052
> Bug: skia:8278
>
> TBR=djsollen@google.com
> As with the original, no API change
>
> Change-Id: I4e5bba6a3151f9dc6491e8eda73d4de0535bd692
> Reviewed-on: https://skia-review.googlesource.com/149043
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Reviewed-by: Leon Scroggins <scroggo@google.com>
TBR=djsollen@google.com,mtklein@google.com,scroggo@google.com,brianosman@google.com
Change-Id: Ie71e1fecc26de8225d2fe603765c1e1e0d738634
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:6839, skia:8052, skia:8278
Reviewed-on: https://skia-review.googlesource.com/149262
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit 33d5394d08,
relanding 81886e8f94 as well as
"Fix CMYK handling in JPEG codec" (commit
f8ae5ce20c)
Add a test based on the CTS test that failed in the original commit.
purple-displayprofile.png is the image used in the CTS test, with the
Android license.
This also adds a fix for SkAndroidCodec, ensuring that we continue to
use a wide gamut SkColorSpace for images that do not have a numerical
transfer function and have a wide gamut. This includes a test, with
wide-gamut.png, which was created with Photoshop and the profile
"sRGB_Calibrated_Homogeneous.icc" from the skcms tree.
Bug: skia:6839
Bug: skia:8052
Bug: skia:8278
TBR=djsollen@google.com
As with the original, no API change
Change-Id: I4e5bba6a3151f9dc6491e8eda73d4de0535bd692
Reviewed-on: https://skia-review.googlesource.com/149043
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
This reverts commit 81886e8f94 and
f8ae5ce20c
("Fix CMYK handling in JPEG codec")
This fixes the Android build, which was failing a CTS test with this
change.
Bug: skia:6839
Bug: skia:8052
TBR=djsollen@google.com
As with the original, no API change
Change-Id: Ic744a610e9f431707f871de44f9f64040bc60d14
Reviewed-on: https://skia-review.googlesource.com/148810
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: skia:6839
Bug: skia:8052
Create an skcms_Profile instead of an SkColorSpace when creating an
SkCodec. Eventually we'll move the SkImageInfo (and its SkColorSpace)
entirely to clients (e.g. SkAndroidCodec, SkCodecImageGenerator), but
for now, create it with SkEncodedInfo::makeImageInfo.
Create new SkEncodedInfo::Colors for the special PNG cases that we
want to map to specific SkColorTypes.
SkEncodedInfo:
- Add ICCProfile, which owns an skcms_ICCProfile
- FIXME: maybe we should have a single instance for
SRGB like SkColorSpace?
- Add kXAlpha_Color, for kAlpha_8. Since I'm not longer creating
an SkImageInfo (at least in SkPngCodec), it needs a way to pass
this info to the caller.
- Add k565_Color, for the same reason. Matt originally had this in
https://codereview.chromium.org/2212563003/#ps120001, but didn't
land that version. I like it though. Mike didn't like the bits
per component for 565, but it seems like a sensible hack, much
like the existing one for kAlpha_8
- Add width and height. These were removed for redundancy with
SkImageInfo, but it makes sense to have them here without it.
BUILD.gn:
- Build the new SkEncodedInfo.cpp
SkCodec:
- Remove the constructor with an SkImageInfo. Edit the other one
to drop width and height (now in SkEncodedInfo) and take a RHS
reference to SkEncodedInfo
- Create the SkImageInfo from fEncodedInfo (for now)
- Consolidate choosing skcms_AlphaFormat for Transform here
- Call conversionSupported from initializeColorXform, with a new
parameter for whether there is a color Xform, allowing SkJpegCodec
and SkHeifCodec to override that method instead of having another
method.
SkBmpCodec (etc)
- Adapt to the changes above
- Create a new SkEncodedInfo w/o profile for the swizzler.
SkPngCodec:
- use the new SkEncodedInfo::Colors rather than a custom SkImageInfo
SkRawCodec:
- Remove SkEncodedInfo from SkDngImage, which doesn't actually need it.
This is helpful since we don't know all the info yet.
- Rewrite gAdobeRGB_toXYZD50 as an skcms_Matrix3x3
SkWebpCodec:
- Remove premul_step computation, and simplify to just rely on
the base class' handling of applying the transform.
SkSwizzler:
- Add cases for the new SkEncodedInfo::Colors
TBR=reed@google.com
No public API changes. Only private/public members of SkCodec.h are
modified.
Change-Id: Ic0d3bb752b03f13be886b80331987aa5a5713fc0
Reviewed-on: https://skia-review.googlesource.com/136062
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
There's really no reason to prevent any of these conversions;
they all have somewhat reasonable behavior:
- converting between grey in different color spaces
should probably work just fine
- we'll convert color to gray using a fixed set of
luminance coefficients, but that's better than failing
- we'll invent {r,g,b} = {0,0,0} if we convert alpha
to something with color
- converting to opaque formats without thinking about
premul/unpremul is probably fine, better than just
not working at all
- a missing src color space can always be assumed to be sRGB
Updates to ReadPixelsTest:
- skip more supported test cases in test_conversion(),
each with a TODO
- conversions from non-opaque to opaque should now work
- conversion from A8 to non-A8 should sometimes now
work on GPUs, and the test needed a little bit of
a tweak to not expect A8 to carry around color somehow.
Updates to SRGBReadWritePixelsTest:
- writing untagged pixels shouldn't fail anymore;
instead, it should behave like it was tagged sRGB
Change-Id: I19e78f3a6c89ef74fbcbc985d3fbd77fa984b1c2
Reviewed-on: https://skia-review.googlesource.com/147815
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The only SkAtomic<T> left are the ones overriding the default memory
order in SkPath. I think I'd like to try switching them to std::atomic
too, but in another CL.
Trim unused APIs in SkAtomics.h.
Change-Id: Ia1c283355902ccb8fcdad70cdf27bb577e8ca407
Reviewed-on: https://skia-review.googlesource.com/146529
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
push -> push_back
add some aliases to match std::vector: count, reserve, ...
Bug: skia:
Change-Id: I1921c31d0d6e5ed3d622a0def6054c697be2d02f
Reviewed-on: https://skia-review.googlesource.com/145884
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
This reverts commit fdf05f4ff4.
Reason for revert: Android fixed after removing multitexture support from TextureOp.
Original change's description:
> Revert "Move GrGeometryProcessor's textures out of classes and into"
>
> This reverts commit af87483873.
>
> Revert "GrGeometryProcessor derives from GrNonAtomicRef not GrProgramElement."
>
> This reverts commit 607be37e3d.
>
> Revert "Store GrMeshDrawOps' meshes in GrOpFlushState's arena."
>
> This reverts commit b948572c78.
>
> Revert "Remove multitexturing support from GrTextureOp."
>
> This reverts commit 986f64c601.
>
> Revert "Make result of GrOp::combineIfPossible be an enum."
>
> This reverts commit 641ac7daa8.
>
> Bug: b/112244393
> Change-Id: I579491a3f2f2f2093f1e2a6141fa1e4cc7b760a4
> Reviewed-on: https://skia-review.googlesource.com/145646
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com
Change-Id: I1d41c2ecf7862e31fb025a7a00bb07bae9d83a47
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: b/112244393
Reviewed-on: https://skia-review.googlesource.com/145780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This is pulled out of: https://skia-review.googlesource.com/c/skia/+/143113 (Reduce arbitrary opList splitting when sorting (take 3)) and is necessary for incremental tological sorting of opLists.
Change-Id: I080cee2c54f5a61dceea67037242f6c6b3e01b8d
Reviewed-on: https://skia-review.googlesource.com/145641
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit af87483873.
Revert "GrGeometryProcessor derives from GrNonAtomicRef not GrProgramElement."
This reverts commit 607be37e3d.
Revert "Store GrMeshDrawOps' meshes in GrOpFlushState's arena."
This reverts commit b948572c78.
Revert "Remove multitexturing support from GrTextureOp."
This reverts commit 986f64c601.
Revert "Make result of GrOp::combineIfPossible be an enum."
This reverts commit 641ac7daa8.
Bug: b/112244393
Change-Id: I579491a3f2f2f2093f1e2a6141fa1e4cc7b760a4
Reviewed-on: https://skia-review.googlesource.com/145646
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
