Code:
- Add a non-linear blending bit and makeNonlinearBlending()
to SkColorSpace
- remove enough F16=linear checks to make it possible to
create surfaces and encode pngs with nonlinear F16
Testing:
- add "esrgb" software config to DM, run it
- add "srgbnl" software config, run it
- deemphasize importance of "srgb" config on bots
- update unit tests to reflect relaxed F16 constraints
- add a new unit test file with _really_ basic tests,
and a new unit test that's not working yet
Bug: skia:7942
Change-Id: I8ac042bdf9f3d791765393b68fd9256375184d83
Reviewed-on: https://skia-review.googlesource.com/127325
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We think we can evolve SkColorSpace_XYZ into the One True SkColorSpace.
Change-Id: If93493145d78b388f3a0739cc7ccd6e232380733
Reviewed-on: https://skia-review.googlesource.com/127326
Auto-Submit: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 101d56359a.
Reason for revert: 5 of 5
Original change's description:
> fonts: Set up remote glyph caching to push fonts.
>
> Currently the SkStrikeClient is designed to pull fonts from the server
> on demand, and to pre-fetch a batched request by analyzing the ops using
> a SkTextBlobCacheDiffCanvas. This change modifies the design to support
> a push based model, where the server pushes fonts required by the client
> and sets up the requisite SkGlyphCaches on the client prior to
> rasterizing the ops.
>
> This model still relies on the SkTextBlobCacheDiffCanvas for analyzing
> the glyphs required for rasterizing an op. The glyph caches required for
> raster are locked and missing glyphs to be sent to the client are tracked
> by the SkStrikeServer. The embedder can serialize this font data at any
> point, but must ensure that this data is deserialized by the
> SkStrikeClient at the remote end, before rasterizing any ops analyzed
> prior to serialization. Any refs on the caches are released once the
> font data is serialized by the server.
>
> The locking of glyph caches relies on the embedder providing discardable
> handles. These handles can be created on the server and serialized to be
> sent to the client, and map to an instance of SkGlyphCache. This allows
> the server to control the lifetime of the caches on the client.
>
> Bug: skia:7515
> Change-Id: Id39f346b47b60899778404bbd0429ee811d0e53b
> Reviewed-on: https://skia-review.googlesource.com/120283
> Commit-Queue: Khusal Sagar <khushalsagar@chromium.org>
> Reviewed-by: Herb Derby <herb@google.com>
TBR=mtklein@google.com,herb@google.com,khushalsagar@chromium.org
Change-Id: If72caf968ddcbf70b8b9d71782a2339a118ed202
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7515
Reviewed-on: https://skia-review.googlesource.com/125264
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Currently the SkStrikeClient is designed to pull fonts from the server
on demand, and to pre-fetch a batched request by analyzing the ops using
a SkTextBlobCacheDiffCanvas. This change modifies the design to support
a push based model, where the server pushes fonts required by the client
and sets up the requisite SkGlyphCaches on the client prior to
rasterizing the ops.
This model still relies on the SkTextBlobCacheDiffCanvas for analyzing
the glyphs required for rasterizing an op. The glyph caches required for
raster are locked and missing glyphs to be sent to the client are tracked
by the SkStrikeServer. The embedder can serialize this font data at any
point, but must ensure that this data is deserialized by the
SkStrikeClient at the remote end, before rasterizing any ops analyzed
prior to serialization. Any refs on the caches are released once the
font data is serialized by the server.
The locking of glyph caches relies on the embedder providing discardable
handles. These handles can be created on the server and serialized to be
sent to the client, and map to an instance of SkGlyphCache. This allows
the server to control the lifetime of the caches on the client.
Bug: skia:7515
Change-Id: Id39f346b47b60899778404bbd0429ee811d0e53b
Reviewed-on: https://skia-review.googlesource.com/120283
Commit-Queue: Khusal Sagar <khushalsagar@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
The implicit SkTCopyOnFirstWrite copy-ctor and assignment operator are
incorrect: fObj must point to the local copy, not to the source copy
(when a copy has been made).
Add corrected explicit copy (and move) ctor + assignment operator.
Also add a get() helper to facilitate rawptr access.
Change-Id: Ie3983e12c04eae4f32c40e3e267618cf02008c20
Reviewed-on: https://skia-review.googlesource.com/120442
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
The big api level change here is that the getBackendInfo calls now return by value
instead of a pointer. These changes are being made in support of Vulkan so that
the client can update the VkImageLayout on the GrBackendTexture and have that
update get reflected in our internal tracking of the image. This is done by storing
a ref counted GrVkImageLayout object on the GrBackendTexture and the GrVkImage.
Bug: skia:
Change-Id: I8c6158fd3a66eb61fef97ebf09ea5364bca3f1ae
Reviewed-on: https://skia-review.googlesource.com/119101
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Performs inset and outset operations on simple polygons and returns
a simple polygon, if possible.
Bug: skia:
Change-Id: I6d468174ad70b5279b736c532e19cbb84ff9f955
Reviewed-on: https://skia-review.googlesource.com/116483
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This will allow a client to make an SkImage that "wraps" a gpu texture,
however the client does need to supply the actual gpu texture at Image
creation time. Instead it is retrieve at flush time via a callback.
Bug: skia:
Change-Id: I6267a55ab7102101a7bd80a6f547b6a870d2df08
Reviewed-on: https://skia-review.googlesource.com/109021
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
This reverts commit 461ef7af88.
Prev CL to SkScan_Hairline.cpp fixed the bug that caused the earlier revert.
Bug: skia:
Change-Id: Ifd9a364c7546175be292f726e19465b72196b45e
Reviewed-on: https://skia-review.googlesource.com/112723
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
For the GrDrawOpAtlas:
At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
It now carries a GrProxyProvider for when it needs to create an atlas
It passes in a GrResourceProvider* at flush time to allow instantiation.
It does not, yet, allocate that GrDrawOpAtlases it might ever require.
TBR=bsalomon@google.com
Change-Id: I276d339d81e7b709140e082a7b58c5584f73ab70
Reviewed-on: https://skia-review.googlesource.com/111100
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This reverts commit 934c3d0c54.
Reason for revert: Chrome
Original change's description:
> Revert "Revert "Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)""
>
> This reverts commit 84d823a5e2.
>
> Reason for revert: The DFT diffs don't repro on Windows so I'm chalking it up to minor device differences
>
> Original change's description:
> > Revert "Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)"
> >
> > This reverts commit 96165ebeaa.
> >
> > Reason for revert: DFT GMs w/ LCD text are slightly different
> >
> > Original change's description:
> > > Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)
> > >
> > > This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
> > >
> > > For the GrDrawOpAtlas:
> > > At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
> > >
> > > The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
> > >
> > > GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
> > >
> > > During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
> > >
> > > The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> > > It now carries a GrProxyProvider for when it needs to create an atlas
> > > It passes in a GrResourceProvider* at flush time to allow instantiation.
> > >
> > > It does not, yet, allocate that GrDrawOpAtlases it might ever require.
> > >
> > > Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
> > > Reviewed-on: https://skia-review.googlesource.com/109749
> > > Reviewed-by: Jim Van Verth <jvanverth@google.com>
> > > Commit-Queue: Robert Phillips <robertphillips@google.com>
> >
> > TBR=jvanverth@google.com,robertphillips@google.com
> >
> > Change-Id: I62efc61c8394477e54d6e79fa2f65180c91a4515
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://skia-review.googlesource.com/110220
> > Reviewed-by: Robert Phillips <robertphillips@google.com>
> > Commit-Queue: Robert Phillips <robertphillips@google.com>
>
> TBR=jvanverth@google.com,robertphillips@google.com
>
> Change-Id: I7c87b4523f9b53285f0de5c2d741a25893522d9a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/110221
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,robertphillips@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I7dd73ab0159f38595f21b21eef3becc10aa0934d
Reviewed-on: https://skia-review.googlesource.com/111080
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 84d823a5e2.
Reason for revert: The DFT diffs don't repro on Windows so I'm chalking it up to minor device differences
Original change's description:
> Revert "Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)"
>
> This reverts commit 96165ebeaa.
>
> Reason for revert: DFT GMs w/ LCD text are slightly different
>
> Original change's description:
> > Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)
> >
> > This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
> >
> > For the GrDrawOpAtlas:
> > At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
> >
> > The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
> >
> > GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
> >
> > During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
> >
> > The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> > It now carries a GrProxyProvider for when it needs to create an atlas
> > It passes in a GrResourceProvider* at flush time to allow instantiation.
> >
> > It does not, yet, allocate that GrDrawOpAtlases it might ever require.
> >
> > Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
> > Reviewed-on: https://skia-review.googlesource.com/109749
> > Reviewed-by: Jim Van Verth <jvanverth@google.com>
> > Commit-Queue: Robert Phillips <robertphillips@google.com>
>
> TBR=jvanverth@google.com,robertphillips@google.com
>
> Change-Id: I62efc61c8394477e54d6e79fa2f65180c91a4515
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/110220
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,robertphillips@google.com
Change-Id: I7c87b4523f9b53285f0de5c2d741a25893522d9a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/110221
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 96165ebeaa.
Reason for revert: DFT GMs w/ LCD text are slightly different
Original change's description:
> Separate creation time & flush time behavior in GrDrawOpAtlas (take 2)
>
> This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
>
> For the GrDrawOpAtlas:
> At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
>
> The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
>
> GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
>
> During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
>
> The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> It now carries a GrProxyProvider for when it needs to create an atlas
> It passes in a GrResourceProvider* at flush time to allow instantiation.
>
> It does not, yet, allocate that GrDrawOpAtlases it might ever require.
>
> Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
> Reviewed-on: https://skia-review.googlesource.com/109749
> Reviewed-by: Jim Van Verth <jvanverth@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=jvanverth@google.com,robertphillips@google.com
Change-Id: I62efc61c8394477e54d6e79fa2f65180c91a4515
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/110220
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
For the GrDrawOpAtlas:
At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
It now carries a GrProxyProvider for when it needs to create an atlas
It passes in a GrResourceProvider* at flush time to allow instantiation.
It does not, yet, allocate that GrDrawOpAtlases it might ever require.
Change-Id: Ie9b64b13e261b01ee14be09fbf7e17841b7781dc
Reviewed-on: https://skia-review.googlesource.com/109749
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 056c1a821a.
Reason for revert: GM issues
Original change's description:
> Separate creation time & flush time behavior in GrDrawOpAtlas
>
> This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
>
> For the GrDrawOpAtlas:
> At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
>
> The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
>
> GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
>
> During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
>
> The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
> It now carries a GrProxyProvider for when it needs to create an atlas
> It passes in a GrResourceProvider* at flush time to allow instantiation.
>
> It does not, yet, allocate that GrDrawOpAtlases it might ever require.
>
> Change-Id: I54909b7a3ba4bec2db5f1218f6a2a3a1636f66d6
> Reviewed-on: https://skia-review.googlesource.com/108520
> Commit-Queue: Robert Phillips <robertphillips@google.com>
> Reviewed-by: Jim Van Verth <jvanverth@google.com>
TBR=jvanverth@google.com,bsalomon@google.com,robertphillips@google.com
Change-Id: I36eafe46209380f533aa84e831d1c9d18844b6be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/109280
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL clarifies what is going on in the GrDrawOpAtlas and GrAtlasGlyphCache.
For the GrDrawOpAtlas:
At creation time all the allowed pages are created (with their backing GrTextureProxies) but they aren't instantiated.
The GrDrawOpAtlas::instantiate call is called in preFlushCB and allocates any pages known to be needed at the start of flush
GrDrawOpAtlas::addToAtlas is called at flush time and, if a new page is activated, will instantiated it at that time.
During compaction, an unused page will be deInstantiated but its Plots and backing GrTextureProxy will remain alive.
The GrAtlasGlyphCache reflects the changes to the GrDrawOpAtlas
It now carries a GrProxyProvider for when it needs to create an atlas
It passes in a GrResourceProvider* at flush time to allow instantiation.
It does not, yet, allocate that GrDrawOpAtlases it might ever require.
Change-Id: I54909b7a3ba4bec2db5f1218f6a2a3a1636f66d6
Reviewed-on: https://skia-review.googlesource.com/108520
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This reverts commit 7df27465c4.
Reason for revert: experimental revert to see if this is the cause of the tree redness
Original change's description:
> Drop support for unused MSAA extensions
>
> Bug: skia:
> Change-Id: I113b80e3f991f195155148625ceb29242ea82776
> Reviewed-on: https://skia-review.googlesource.com/101403
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
TBR=bsalomon@google.com,csmartdalton@google.com,ethannicholas@google.com
Change-Id: I4fa4123e2d176bef88cd76a09a14053d9ac5809f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/101680
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: b/63908092
By default use the repetition count stored in the encoded data (if
any). Allow setting the repetition count manually, so that the
animation will stop after n+1 total cycles (unless -1 is used for
infinite).
If the animation is complete, make start reset it.
When the animation is not running, make update return max double (i.e.
no need to update any time soon).
Fix a bug where the first call to update returned -1.
Share write_bm with CodecAnimTest, for debugging.
Update Sample to check isRunning rather than keeping its own record
of whether the animation is running.
Change-Id: I883e4d7325f7a7b23a422fa9d756f9ea3018f0f8
Reviewed-on: https://skia-review.googlesource.com/97082
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This patch uses equal_range instead of linear search to look up a
factory entry by name. This does require a sort, but the expected usage
is that the sort happens once and look ups happen many times.
This improves performance on Chromium's oop deserialization of
flattenables by about 10%
R=reed@chromium.org
Change-Id: I907f457a2ffb7d5b6d8261343099d982260b8415
Reviewed-on: https://skia-review.googlesource.com/96820
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: b/63909536
Android's ImageDecoder API takes as input an arbitrary width and height
to scale the image to. Internally, this uses SkAndroidCodec to sample,
and then (if not a perfect match) scales to the desired size with
drawing.
computeSampledSize is a modified version of what ImageDecoder currently
does to convert from arbitrary dimensions to a sampleSize. Moving it
here allows it to be shared by SkAnimatedImage. The modified version
also corrects two bugs:
- a client using the dimensions returned by getSampledDimensions
previously may have resulted in ImageDecoder decoding to a larger
size and then scaling it. (example found in tests: dog.jpg is
180 x 180. getSampledDimensions(8) returns 23 x 23, but the old
method resulted in using sampleSize of 7 and downscaling the resulting
25 x 25 image.)
- recompute the sampleSize based on the size returned by
getSampledDimensions.
Change-Id: I022040e8bac31c20988903a0452257f7ae902bc7
Reviewed-on: https://skia-review.googlesource.com/94620
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
We need to discriminate between nodes whose bounds updates contribute to the dirty
region, and nodes whose bounds changes do not.
E.g. animated shape in a group: the animated shape node bounds should yield damage,
but the ancestor group bounds should not.
To accomplish this, we refine the invalidation state:
1) self invalidation == the node itself was invalidated, and its bounds updates
yield damage.
2) descendant invalidation == the node has some (self-)invalidated descendant,
but its own bounds are not contributing damage.
Also:
* hoist the bounding box invalidation logic into the base class (Node::revalidate)
and update to respect the states described above.
* remove (now-redundant) GeometryNode bbox logic.
* update revalidation methods to return the node bbox instead of void
TBR=
Change-Id: I8023d1793fb501c945a53f2dc2d2983e5b620ade
Reviewed-on: https://skia-review.googlesource.com/90581
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Some interesting things are starting to fall out already,
like the fact that I needed to add a gamma_dst stage to
be able to draw into gamma-transfer-fn destinations.
I've also had to pass an SkAlphaType through to the linearize
functions so that they can maintain premul invariants. I'm not
sure this is actually a good idea... if you can, please double-
check my logic at SkRasterPipeline.cpp:128?
If it's correct logic, I'm going to need to do it all over the place.
But I imagine you don't do this and somehow get away with it.
Change-Id: I42cd9b161b54287d674225103ad9e19f8b388959
Reviewed-on: https://skia-review.googlesource.com/84680
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
I was wondering how feasible using this to make downcasts safe would be.
These tests would need to build and pass on all our bots, at least.
Change-Id: I1753ba58841bf6c17d6ac3af7374518356e1bb05
Reviewed-on: https://skia-review.googlesource.com/81180
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
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>
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>
This was uncovered by the linked fuzzer issue.
I haven't looked hard at it, but I'd guess it's fuzzed an ICC profile
into one that can't be deserialized, and we get a null in CreateProc().
We could probably restrict the null check to just CreateProc(), but
putting it in Make() and asserting in the constructor feels cozy.
BUG=chromium:787718
Change-Id: Ic4b1dad28c00ee5870f22093eedbf34686c32120
Reviewed-on: https://skia-review.googlesource.com/76080
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
This patch fixes an assert that triggers when removing the last
extension in the list, since the index operator goes out of bounds.
Added a test that fails without the code changes and passes with the
changes.
R=bsalomon@chromium.org
Change-Id: I0d561b150899c178f638dde088af773fddf112d9
Reviewed-on: https://skia-review.googlesource.com/72000
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: Brian Salomon <bsalomon@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>
