Also remove unused position variable parameter.
Change-Id: I37f98a03ac1ca750810de13b08e3ffa11e41828c
Reviewed-on: https://skia-review.googlesource.com/81320
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This partially reverts commit
1793e7bb46.
Hide SkEncodedInfo
Bug: skia:7353
Bug: skia:6839
This contains information that is not necessary for clients to know. The
Color enum tells the number of components in the input, but this is only
interesting internally (to the SkSwizzler).
Similarly, the Alpha enum differs from SkAlphaType in that it has
kBinary instead of kPremul. This is useful information only internally
for determining whether the SkColorSpaceXform needs to premultiply.
The bitsPerComponent is potentially useful for a client; Android (in
SkAndroidCodec) uses it to determine the SkColorType. Rather than
exposing bitsPerComponent, make SkAndroidCodec a friend so it can
access the SkEncodedInfo. A future change will change SkCodec to
recommend F16 for bitsPerComponent > 8, but that will be more involved;
it was the reason for the revert of this CL.
Switch conversionSupported to use an SkColorType, which is enough info.
Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
SkAlphaType.
SkCodec still needs an SkEncodedInfo, so move its header (which is
already not SK_API) to include/private.
TBR=mtklein@chromium.org,reed@google.com
Change-Id: I928b1f55317602cb37d29da63b53026c8d139cee
Reviewed-on: https://skia-review.googlesource.com/80860
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit c6f7a4ffa9.
Reason for revert: Causing differences in Gold, stemming from the fact that this changes the recommended SkImageInfo for 16 bits-per-component PNG from N32 to F16.
- an F16 bitmap already png-encodes to a 16 bits-per-component PNG, but it does not encode a linear colorspace (possibly a bug?). when we decode this PNG using getInfo(), it fails because it has an F16 color type and non-linear colorspace. (In the encode-srgb-png gm, this results in blank results for F16.) We could correct this on the encoder side, but it seems possible that a 16 bits-per-component PNG could be encoded with a different color space. In that case, we'd want SkCodec to recommend F16/SRGBLinear, but I think we'd want the SkCodec to store the encoded SkColorSpace so that we can Xform between the two. Currently SkCodec only stores one color space, so that will require a refactor.
- When decoding 16-bits-per-component PNGs, we are now decoding them to F16. This shows differences in Gold. The srgb/gpu results now look more like F16. I think this is fine.
Original change's description:
> Hide SkEncodedInfo
>
> Bug: skia:7353
> Bug: skia:6839
>
> This contains information that is not necessary for clients to know. The
> Color enum tells the number of components in the input, but this is only
> interesting internally (to the SkSwizzler).
>
> Similarly, the Alpha enum differs from SkAlphaType in that it has
> kBinary instead of kPremul. This is useful information only internally
> for determining whether the SkColorSpaceXform needs to premultiply.
>
> The bitsPerComponent is potentially useful for a client; Android (in
> SkAndroidCodec) uses it to determine the SkColorType. Rather than
> exposing bitsPerComponent, use it to make the same decision that Android
> would have made - 16 bits per component means to set the info to F16. Add
> a test that computeOutputColorType behaves as expected.
>
> Switch conversionSupported to use an SkColorType, which is enough info.
>
> Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
> SkAlphaType.
>
> SkCodec still needs an SkEncodedInfo, so move its header (which is
> already not SK_API) to include/private.
>
> Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda
> Reviewed-on: https://skia-review.googlesource.com/79260
> Reviewed-by: Mike Reed <reed@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Leon Scroggins <scroggo@google.com>
TBR=mtklein@chromium.org,scroggo@google.com,reed@google.com
Change-Id: I0c5dd1461e1b70d1e55349a8e7ee6b029c3f556e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7353, skia:6839
Reviewed-on: https://skia-review.googlesource.com/80660
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: skia:7353
Bug: skia:6839
This contains information that is not necessary for clients to know. The
Color enum tells the number of components in the input, but this is only
interesting internally (to the SkSwizzler).
Similarly, the Alpha enum differs from SkAlphaType in that it has
kBinary instead of kPremul. This is useful information only internally
for determining whether the SkColorSpaceXform needs to premultiply.
The bitsPerComponent is potentially useful for a client; Android (in
SkAndroidCodec) uses it to determine the SkColorType. Rather than
exposing bitsPerComponent, use it to make the same decision that Android
would have made - 16 bits per component means to set the info to F16. Add
a test that computeOutputColorType behaves as expected.
Switch conversionSupported to use an SkColorType, which is enough info.
Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
SkAlphaType.
SkCodec still needs an SkEncodedInfo, so move its header (which is
already not SK_API) to include/private.
Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda
Reviewed-on: https://skia-review.googlesource.com/79260
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This should be it for now except for maybe a GrMipMapped field.
Change-Id: I8f20a1048eaa8cd2b5eab5f42ca58c61649f72e7
Reviewed-on: https://skia-review.googlesource.com/78440
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Adds ultra-deferred proxies that are instantiated by a user-supplied
callback during flush.
Bug: skia:7190
Change-Id: I75a7ac6dba953c3b0a99febc203a7f4d2f3789fc
Reviewed-on: https://skia-review.googlesource.com/76461
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Ganesh will require access to the GrCaps to make rendering decisions.
Change-Id: I6dee42a3f0dc638f052706b8d1ea6e02b589e062
Reviewed-on: https://skia-review.googlesource.com/77681
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Yes/no enums should have a base type of bool, and kYes should always
be true. Also, there is no need for a "GrEnumToBool()" function, as we
can just use the enum itself directly: e.g. "GrAA(bool)".
Bug: skia:
Change-Id: I7bb3c2983f717f3467fca4ce6b32920d71026894
Reviewed-on: https://skia-review.googlesource.com/74860
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This change swaps the sense of the tonal color shadow flag, so
tonal color will always be on unless explicitly disabled.
Change-Id: I56ce4228022cf59b570cd7461327628cf7fe7173
Reviewed-on: https://skia-review.googlesource.com/73900
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This is a reland of e421800227
Original change's description:
> Fix precision caps and rrect/ellipse effect precisions
>
> Replaces all the complex precision caps with a single flag that says
> whether "float" == fp32. Updates the ellipse and rrect effects to
> use float coords, and use the scale workaround when float != fp32.
>
> Bug: skia:7190
> Change-Id: Ieccff9f38acd05e5cec78fe90d01a5da901a9307
> Reviewed-on: https://skia-review.googlesource.com/70961
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com
Bug: skia:7190
Change-Id: I7ced37a64164b83d86f6a957c35e10ce9085aba0
Reviewed-on: https://skia-review.googlesource.com/72760
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This reverts commit e421800227.
Reason for revert: Also may be responsible for layout test failures? Playing it safe.
Original change's description:
> Fix precision caps and rrect/ellipse effect precisions
>
> Replaces all the complex precision caps with a single flag that says
> whether "float" == fp32. Updates the ellipse and rrect effects to
> use float coords, and use the scale workaround when float != fp32.
>
> Bug: skia:7190
> Change-Id: Ieccff9f38acd05e5cec78fe90d01a5da901a9307
> Reviewed-on: https://skia-review.googlesource.com/70961
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=egdaniel@google.com,bsalomon@google.com,csmartdalton@google.com,ethannicholas@google.com
Change-Id: Idca2f0390e7a0eb85010255183f2f27332b8d26d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7190
Reviewed-on: https://skia-review.googlesource.com/72540
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Replaces all the complex precision caps with a single flag that says
whether "float" == fp32. Updates the ellipse and rrect effects to
use float coords, and use the scale workaround when float != fp32.
Bug: skia:7190
Change-Id: Ieccff9f38acd05e5cec78fe90d01a5da901a9307
Reviewed-on: https://skia-review.googlesource.com/70961
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This isn't used and has become a maintenance burden.
Change-Id: I5f3af8f91e5c4f073fe4ea30e0a7f1f61efeea47
Reviewed-on: https://skia-review.googlesource.com/70640
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Change-Id: Id31de8dc0d9d68369896f2686068b29e07135a39
Reviewed-on: https://skia-review.googlesource.com/68641
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
The current usage of CCPR by clipping code is suboptimal. This is
causing regressions on the bots and projects like Flutter that make
heavy use of clipPath. Disabling CCPR while we fix it up.
Bug: skia:7190
Bug: flutter:12839
Change-Id: I03af5249b53cf2eab5a13d85a5f87708030c8666
Reviewed-on: https://skia-review.googlesource.com/67920
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Bug: skia:
Change-Id: I482d8f9937c86ed441016afef2d8f924282dd17a
Reviewed-on: https://skia-review.googlesource.com/63861
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Additionally this changed triggered a cascade of plumbing GrMipMapped
down throughout Ganesh.
Bug: skia:
Change-Id: I4181f44d9046d66139bb491c7abf86703305aaeb
Reviewed-on: https://skia-review.googlesource.com/63000
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This introduces skstd::index_sequence and skstd::make_index_sequence so
that these can be used in C++11. These are mostly equivalent to their
std:: counterparts. This also introduces SkMakeArray<N, C>
which is constexpr and creates a std::array with N elements with each
element being initialized with the value of C(i) where i is the index of
the element.
These are then used to create inverse gamma table at compile time. This
avoids threading issues.
BUG=skia:7187
Change-Id: I61fb10a778898652e546d54c104a08d6e6bf88d3
Reviewed-on: https://skia-review.googlesource.com/61380
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Because what can be better than marking things that can be constexpr as
constexpr. Also, I have a change where this would be nice to have.
Change-Id: Ie313b19d1930b98ddcd60cc17a320971625f18e3
Reviewed-on: https://skia-review.googlesource.com/60862
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
