We now store 3x3 matrices, and cache all
destination inversion, not just the matrix.
The 4x4's are still there to support existing APIs,
including the guard flag added for layout tests.
There will be tons of tiny diffs from the inversion
changes, both from inverting transfer functions and
from inverting the matrix.
This doesn't change the numbers I'm seeing in nanobench,
but it does move the matrix concat and tf invert way
down the profile.
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I66be4a84f12c4fefaf6ac2105d5c82e66d6b42e7
Reviewed-on: https://skia-review.googlesource.com/157522
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
After sk_imageinfo was initially created, we have added a colorspace to it,
and that object is a smart-pointer. In response to that, this CL upgrades
imageinfo to an "object" (like paint), so we can manage the ref-counting of
its colorspace, and to allow for future changes/expansion (like paint).
Bug: skia:
Change-Id: I629ff99c0820fdbe83f062d9fb768c15cda68e18
Reviewed-on: https://skia-review.googlesource.com/157156
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Currently, the GPU code uses the unified code path
in painter to draw. Have the remote glyph cache use it too.
Moved a function out of the GPU flag.
Change-Id: I1d0bfc7edff0fd8731ea6cbf0b5b05aad537c3c6
Reviewed-on: https://skia-review.googlesource.com/157760
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Bug: skia:
Change-Id: Ie59aace6ba7ca3685d481fcb3af508629c56f0c3
Reviewed-on: https://skia-review.googlesource.com/157742
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change encode-srgb-* to exercise this code. The encoders
handle this just fine, so just remove those checks. The
decoders still rely on having a color space, so detect
and fix this inside SkCodec. Eventually I'd like to get
rid of the swizzler, use skcms for all format conversion,
etc... but that's a really big change, and this will let
us land other changes without breaking layout tests.
Bug: skia:8382
Change-Id: I8d85bf44ee3a287ad295515a745ded2ff5051417
Reviewed-on: https://skia-review.googlesource.com/156627
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:8417
Change-Id: Ida8517b959e7d521ae3ebd002ae84e4c55008ad2
Reviewed-on: https://skia-review.googlesource.com/157423
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Converts GrResourceProvider::Flags and GrResourceCache::ScratchFlags
to "enum class" and fixes a case where we were accidentally using the
wrong type of flag. Makes sure to allocate GrSWMaskHelper proxies with
kNoPendingIO.
Bug: skia:8351
Change-Id: Ibcaa26314a53d0cb31ae22915ab94ab0fc07e76d
Reviewed-on: https://skia-review.googlesource.com/157280
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
In macOS 14 the font smoothing behavior was changed. On macOS 13 and lower
requesting smoothing would either do nothing or apply fake bolding and
subpixel coverage, depending on a user setting. On macOS 14 this same user
setting causes smoothing to either do nothing or apply fake bolding. Skia
had been checking for subpixel coverage to know whether to ask for
smoothing, but since subpixel coverage is no longer provided Skia won't
ask for smoothing. However, some still want to see the fake bolding.
This changes behavior in Skia to detect if requesting smoothing does not
change the rendering, if it changes the rendering, or if it changes the
rendering and applies subpixel coverage. The code which conflated the
changing of rendering and subpixel coverage is updated to check for the
appropriate conditions.
This has the odd effect of making the setLCDRenderText setting in Skia on
macOS 14 not actually turn on subpixel coverage but instead apply
fake-bolding to closest match the behavior of the request on previous
versions of macOS.
Bug: chromium:858861
Change-Id: Ic7ff22e171a15be20e0bcccb10b0c4798cba8b72
Reviewed-on: https://skia-review.googlesource.com/157566
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Currently, the GPU code uses the unified code path
in painter to draw. Have the remote glyph cache use it too.
Change-Id: Ibb1728a9602dbb3ace3a57781c5e7a20cdbe3cdf
Reviewed-on: https://skia-review.googlesource.com/157521
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is a reland of 42e086cd2d
Original change's description:
> Change how GrTextureOp computes outset vertices.
>
> Rather than intersecting outset edge equations we outset each vertex
> half a pixel along its two adjacent edges.
>
> This approach will allow for water tight seams along shared edges
> when we allow a subset of the quad edges to be antialiased.
>
> Bug: skia:
> Change-Id: I7f36ea658cc84dfcf364b138ec382bb709c278df
> Reviewed-on: https://skia-review.googlesource.com/156742
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:
Change-Id: I518ddf1d1bd6d7b8234db9ccba3c495eb42f3f1d
Reviewed-on: https://skia-review.googlesource.com/157562
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@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>
Adds an interface for the document creator to pass in a tree
of tags indicating the structure of the document, each with a type
(from a predetermined enum of possible types) and a node ID.
It also adds a setNodeId function to SkCanvas so that page content
can be associated with a particular tag. If both the tag tree and
marked content are present, Skia can now output a properly tagged
PDF.
An example program is included. When used properly, the PDF generated
by this patch is valid and the tags are parsed properly by Adobe
Acrobat. It handles many corner cases like content that spans more
than one page, or tags that don't correspond to any marked content, or
marked content that doesn't correspond to any tags.
However, it doesn't implement all of the features of PDF accessibility
yet, there are some additional attributes that can be associated with
some tags that need to be supported, too, in order to properly tag
things like figures and tables.
Bug: skia:8148
Change-Id: I2e448eca8ded8e1b29ba685663b557ae7ad7e23e
Reviewed-on: https://skia-review.googlesource.com/141138
Reviewed-by: Hal Canary <halcanary@google.com>
In particular:
- GraphicStateEntry no longer holds copy of SkClipStack.
- ContentEntries are now usually concatinated together and include
serialized GraphicStateEntry deltas.
- One GraphicStackState is kept on the pdfdevice, for the currently
active ContentEntry.
16% reduction in RAM use for running all GMs through SkPDF.
97% reduction in RAM use for a particular test case:
SkRandom rand;
SkPaint paint;
for (int i = 400000; i-- > 0;) {
SkPoint p0 = {0, (float)rand.nextRangeU(0, 792)};
SkPoint p1 = {612, (float)rand.nextRangeU(0, 792)};
canvas->drawLine(p0, p1, paint);
}
Bug: skia:8397
Change-Id: Ieb86c0eabac45b120a97fe5c749fdb26d8a85267
Reviewed-on: https://skia-review.googlesource.com/157340
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Currently, the fallback helper is a static used by the GPU
code to handle fallback glyphs. This code must be common to
both GPU and Renderer so it needs to be in the Painter.
Change-Id: I367a87b1dc785d67996a13ee42d74f2162c1b765
Reviewed-on: https://skia-review.googlesource.com/157300
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Bug: skia:
Change-Id: Ie2c59b2363a8ac3dee2a835d94c4106f4692aa24
Reviewed-on: https://skia-review.googlesource.com/157426
Auto-Submit: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit f065907ccc.
Reason for revert: Processor test failing (inconsistently) on several bots.
Original change's description:
> Reland "Implement an explicit binary search-based analytic gradient colorizer"
>
> This reverts commit 9461dcf130.
>
> Reason for revert: Fixes for ANGLE's incorrect shader behavior
>
> Original change's description:
> > Revert "Implement an explicit binary search-based analytic gradient colorizer"
> >
> > This reverts commit dcc85fc610.
> >
> > Reason for revert: ANGLE is frequently corrupted, particularly radial_gradient4 and mixershader
> >
> > Original change's description:
> > > Implement an explicit binary search-based analytic gradient colorizer
> > >
> > > Provides a reasonably flexible fragment processor that defines another
> > > colorizer implementation for gradients. It can support up to 8
> > > interpolation intervals (which is 16 colors if every stop is a hard stop
> > > or 9 colors if every stop is a smooth transition). It
> > > supports mixtures of hard and smooth stops. It is conditionally compiled
> > > into versions specific to the interval count (so it can produce up to
> > > 8 shader variants).
> > >
> > > The GrGradientShader controller does not remove the single and dual
> > > interval colorizers, which are useful specializations of this explicit
> > > binary search colorizer. Similarly, since it can only handle up to 8
> > > intervals, the texture colorizer is still used as a fallback.
> > >
> > > Currently it does not employ capabilities detection to determine if the
> > > hardware can support the number of required uniforms, which can become
> > > substantial for the larger gradient configurations.
> > >
> > > Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
> > > Change-Id: Ia1f735a5019766ae4796cc22964b2913db34b95b
> > > Reviewed-on: https://skia-review.googlesource.com/155080
> > > Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> > > Reviewed-by: Brian Osman <brianosman@google.com>
> >
> > TBR=bsalomon@google.com,brianosman@google.com,michaelludwig@google.com
> >
> > Change-Id: I351a387f0528e4c2db2d47ab2e5d6b336991fb98
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
> > Reviewed-on: https://skia-review.googlesource.com/156541
> > Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> > Commit-Queue: Michael Ludwig <michaelludwig@google.com>
>
> TBR=bsalomon@google.com,brianosman@google.com,michaelludwig@google.com
>
> Change-Id: I2aca36307d88c26905d860ec29417ec68c6037cc
> Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
> Reviewed-on: https://skia-review.googlesource.com/156542
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
TBR=bsalomon@google.com,brianosman@google.com,michaelludwig@google.com
Change-Id: Icd925d568d8cdffdc3020c07a9c50a4aa9cf0bb9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
Reviewed-on: https://skia-review.googlesource.com/157429
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 42e086cd2d.
Reason for revert: Breaking layout tests (just need rebaseline)
Original change's description:
> Change how GrTextureOp computes outset vertices.
>
> Rather than intersecting outset edge equations we outset each vertex
> half a pixel along its two adjacent edges.
>
> This approach will allow for water tight seams along shared edges
> when we allow a subset of the quad edges to be antialiased.
>
> Bug: skia:
> Change-Id: I7f36ea658cc84dfcf364b138ec382bb709c278df
> Reviewed-on: https://skia-review.googlesource.com/156742
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,brianosman@google.com
Change-Id: I0f293dda19507a0af33cadf24b8b5f807d391d9a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/157427
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 9461dcf130.
Reason for revert: Fixes for ANGLE's incorrect shader behavior
Original change's description:
> Revert "Implement an explicit binary search-based analytic gradient colorizer"
>
> This reverts commit dcc85fc610.
>
> Reason for revert: ANGLE is frequently corrupted, particularly radial_gradient4 and mixershader
>
> Original change's description:
> > Implement an explicit binary search-based analytic gradient colorizer
> >
> > Provides a reasonably flexible fragment processor that defines another
> > colorizer implementation for gradients. It can support up to 8
> > interpolation intervals (which is 16 colors if every stop is a hard stop
> > or 9 colors if every stop is a smooth transition). It
> > supports mixtures of hard and smooth stops. It is conditionally compiled
> > into versions specific to the interval count (so it can produce up to
> > 8 shader variants).
> >
> > The GrGradientShader controller does not remove the single and dual
> > interval colorizers, which are useful specializations of this explicit
> > binary search colorizer. Similarly, since it can only handle up to 8
> > intervals, the texture colorizer is still used as a fallback.
> >
> > Currently it does not employ capabilities detection to determine if the
> > hardware can support the number of required uniforms, which can become
> > substantial for the larger gradient configurations.
> >
> > Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
> > Change-Id: Ia1f735a5019766ae4796cc22964b2913db34b95b
> > Reviewed-on: https://skia-review.googlesource.com/155080
> > Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
>
> TBR=bsalomon@google.com,brianosman@google.com,michaelludwig@google.com
>
> Change-Id: I351a387f0528e4c2db2d47ab2e5d6b336991fb98
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
> Reviewed-on: https://skia-review.googlesource.com/156541
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
TBR=bsalomon@google.com,brianosman@google.com,michaelludwig@google.com
Change-Id: I2aca36307d88c26905d860ec29417ec68c6037cc
Bug: chromium:796479, chromium:729727, chromium:696603, chromium:543625, chromium:414254
Reviewed-on: https://skia-review.googlesource.com/156542
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
It's possible to change path bounds by changing path points using
SkPath::setLastPt(), but we don't invalidate the bounds when we do.
Seems like the best thing to do is to invalidate the bounds when
we attach an editor, the same way we invalidate the gen ID.
Bug: oss-fuzz:10488, oss-fuzz:10698
Change-Id: Idd04d37f9e39979aac135d675aa4e5949c55a453
Reviewed-on: https://skia-review.googlesource.com/156700
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
1) print out that there is a problem and
what that problem is
2) switch to %g so we can see very small points
3) return false when the bounds aren't valid
Bug: oss-fuzz:10488
Change-Id: I2a8a5611ba6459f1bd45e29a1f20510401e86f76
Reviewed-on: https://skia-review.googlesource.com/156662
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Rather than intersecting outset edge equations we outset each vertex
half a pixel along its two adjacent edges.
This approach will allow for water tight seams along shared edges
when we allow a subset of the quad edges to be antialiased.
Bug: skia:
Change-Id: I7f36ea658cc84dfcf364b138ec382bb709c278df
Reviewed-on: https://skia-review.googlesource.com/156742
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: b/116608007
Change-Id: I622165d5c63f3a8548e763899128b3eb4b8459a6
Reviewed-on: https://skia-review.googlesource.com/157420
Auto-Submit: Leon Scroggins <scroggo@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The "pointy vertex" test was only considering the distance from the
next (outgoing) edge to the previous point. It must also consider the
distance from the previous (incoming) edge to the next point. If
either are less than a quarter pixel, the vertex is considered pointy
and should be removed. (884166)
Also (887103), when an interior region was completely removed due to
boundary simplification, it would leave a degenerate edge consisting
of the same vertex. So avoid introducing a join edge when prev == next.
Bug: 884166, 887103
Change-Id: I7f1d5b98e418d8f2a1c11643259d3cd74d08f286
Reviewed-on: https://skia-review.googlesource.com/157220
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
- gammaencodedpremul GM was just demonstrating something that we
understand well (and have much better testing for).
- readpixels GM was filled with workarounds for things that are no
longer true (unpremul images, clamped F16).
- Other uses can be switched to SkConvertPixels trivially.
- Remove SkColorSpaceXformPriv and SkColorLookUpTable, all unused.
- Remove SkColorSpaceXform_skcms.cpp, no longer referenced by clients.
Bug: skia:
Change-Id: I7298bb53aa61b49ad1398ebc504d35c119fd5cf4
Reviewed-on: https://skia-review.googlesource.com/157153
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 06f69eb296.
Reason for revert: SKPBench dying
Original change's description:
> Fix bug in GM's DDL drawing mode
>
> Due to how we were constructing the promise images we weren't hitting this before.
>
> It is possible, when re-inflating the images of an SKP, that a draw occurs to create an image subset. When this occurs it is crucial that the generated opList be added to the appropriate drawing manager (so that it gets copied into the DDL).
>
> This CL gets rid of the prior hack. It does have the (minor) downside that the SkDDLRecorders are now all created outside of their thread silos.
>
> Change-Id: Ic6b23a8b68c0d4fe25dd8588c6e2ab65f9f238cf
> Reviewed-on: https://skia-review.googlesource.com/157080
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
TBR=egdaniel@google.com,robertphillips@google.com
Change-Id: Ia52094ce0e356b77b025a7352f2cc728df77d259
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/157223
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Due to how we were constructing the promise images we weren't hitting this before.
It is possible, when re-inflating the images of an SKP, that a draw occurs to create an image subset. When this occurs it is crucial that the generated opList be added to the appropriate drawing manager (so that it gets copied into the DDL).
This CL gets rid of the prior hack. It does have the (minor) downside that the SkDDLRecorders are now all created outside of their thread silos.
Change-Id: Ic6b23a8b68c0d4fe25dd8588c6e2ab65f9f238cf
Reviewed-on: https://skia-review.googlesource.com/157080
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: skia:
Change-Id: I55a6a2ce4709cf751ff8947d4e1c6c60dfe35628
Reviewed-on: https://skia-review.googlesource.com/157081
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Bug: oss-fuzz:9884
Change-Id: Ibeeb1ffdb46d9a648c7ec8944424af2d0138af59
Reviewed-on: https://skia-review.googlesource.com/156631
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Yuqian Li <liyuqian@google.com>
This reverts commit a8b20a1af7.
Reason for revert: breaking some bots
Original change's description:
> Add support for RGB config to Vulkan.
>
> This adds support for RGB, but from investigating, most desktops don't
> support RGB at all, and on Android it is usually support as a linear
> format and not necessarily an optimal one. So until we get better support
> for linear formats this CL doesn't necessarily add more feature support to
> our vulkan backend.
>
> Bug: skia:8349
> Change-Id: I1066ddafa660a1ef1d90dbf3e127e067d6132d45
> Reviewed-on: https://skia-review.googlesource.com/156600
> Commit-Queue: Greg Daniel <egdaniel@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=egdaniel@google.com,robertphillips@google.com
Change-Id: Ibb7b67c36a1dbcf0d670e0ff293003eac23b5ac4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:8349
Reviewed-on: https://skia-review.googlesource.com/156940
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Extract this code and use it on the GPU side in preparation
to have both GPU and Renderer use it.
Change-Id: I1c6f64b9096b2dbccfc09e9d9dc099c2a10ed6d7
Reviewed-on: https://skia-review.googlesource.com/154560
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This adds support for RGB, but from investigating, most desktops don't
support RGB at all, and on Android it is usually support as a linear
format and not necessarily an optimal one. So until we get better support
for linear formats this CL doesn't necessarily add more feature support to
our vulkan backend.
Bug: skia:8349
Change-Id: I1066ddafa660a1ef1d90dbf3e127e067d6132d45
Reviewed-on: https://skia-review.googlesource.com/156600
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Bug: oss-fuzz:9012
Change-Id: I93242447e20d0dda7740a31ad330e0fccdb56fc8
Reviewed-on: https://skia-review.googlesource.com/156800
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
All test PDFs render the same.
Change-Id: Ia3b8fb8a9a1a9e68fe79e02e8c816cc562cf6fe8
Reviewed-on: https://skia-review.googlesource.com/156760
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Removes the CCPR blacklist for Vulkan, and disables geometry shaders
on Vulkan while we continue to investigate http://skbug.com/7733.
Bug: skia:7733
Bug: skia:8408
Change-Id: I85b89a2f0170abed946441adbbf7c0b075897096
Reviewed-on: https://skia-review.googlesource.com/153625
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This may just be a suggested color type, but it's better than nothing.
In conjunction with a codec change, this would make it possible to
detect 8 vs. 16-bit PNG, for example.
Bug: skia:
Change-Id: I0886cca004b10ac9707c66e816316cf6f822ab01
Reviewed-on: https://skia-review.googlesource.com/156640
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
