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>
