properties (color space), bounds, and (optional) alphaType.
We were being pretty inconsistent before. Raster was honoring all
components of the info. GPU was using the supplied color type, but
propagating the source's color space. All call sites were saying N32.
What we want to do is propagate the original device's color space, and
pick a good format from that. Rather than force all the clients to
jump through hoops constructing an SkImageInfo that meets our criteria,
just have them supply the few bits we care about, and do everything else
internally.
This also lets us always use RGBA on GPU, but N32 on raster.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
Committed: https://skia.googlesource.com/skia/+/53c38087949252d27cde668368a3eeb59cc2eb00
Review-Url: https://codereview.chromium.org/2349373004
Reason for revert:
DM crash and/or TSAN failure
Original issue's description:
> Change SkSpecialImage::makeSurface and makeTightSurface to take output
> properties (color space), bounds, and (optional) alphaType.
>
> We were being pretty inconsistent before. Raster was honoring all
> components of the info. GPU was using the supplied color type, but
> propagating the source's color space. All call sites were saying N32.
>
> What we want to do is propagate the original device's color space, and
> pick a good format from that. Rather than force all the clients to
> jump through hoops constructing an SkImageInfo that meets our criteria,
> just have them supply the few bits we care about, and do everything else
> internally.
>
> This also lets us always use RGBA on GPU, but N32 on raster.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
>
> Committed: https://skia.googlesource.com/skia/+/53c38087949252d27cde668368a3eeb59cc2eb00TBR=robertphillips@google.com,reed@google.com,bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2366723004
properties (color space), bounds, and (optional) alphaType.
We were being pretty inconsistent before. Raster was honoring all
components of the info. GPU was using the supplied color type, but
propagating the source's color space. All call sites were saying N32.
What we want to do is propagate the original device's color space, and
pick a good format from that. Rather than force all the clients to
jump through hoops constructing an SkImageInfo that meets our criteria,
just have them supply the few bits we care about, and do everything else
internally.
This also lets us always use RGBA on GPU, but N32 on raster.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
Review-Url: https://codereview.chromium.org/2349373004
Net effect of the two calls is (basically) the same, but given that we're
propagating from isGammaCorrect on the DC, I figured it makes sense to use
the same-named API.
More importantly, a couple places had slipped through, so those draws would
ignore sRGB-ness of inputs entirely.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357413004
Review-Url: https://codereview.chromium.org/2357413004
For now, this is just the color space (of the original
requesting device). This is used when constructing
intermediate rendering surfaces, so that we ensure we
land in a surface that's similar/compatible to the
final consumer of the DAG's output.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357273002
Review-Url: https://codereview.chromium.org/2357273002
On the pure-GPU path, we just have an SkSpecialImage (that's definitely
texture backed), and we need a renderable config for the draw context we
make. Added a helper function to pick - this is basically the high
precision analog of what we were doing before (always using 8888).
The assert that I added catches many other problems in image filter code,
but those fixes are coming in subsequent CLs.
12 GMs render correctly (or more correctly) in gpusrgb and gpuf16
configs. In most cases, they were drawing previously nothing.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2359443003
Review-Url: https://codereview.chromium.org/2359443003
Three distinct issues exposed by Fuzzer:
1) truncating the flags to 8 bits may trip the assert in SkToU8
Since clients can pass in any garbage, we cannot assume it fits in 8
bits. Just static_cast<> instead.
2) vertical gradients with dx == -0.0 don't trigger interval inversion.
For dx < 0 we want reversed intervals. But, alas, -0.0 < 0 == false
(thanks, Ob^WIEEE 754!). Use signbit() instead.
3) half closed range checking needs to be inverted for reversed
intervals.
Normally we check for [p0, p1), but for reversed intervals (p1 < p0) we
want to check for [p1, p0), and not (p1, p0]. Adjust the logic
accordingly.
BUG=skia:5647
R=reed@google.com,kjlubick@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349153004
Review-Url: https://codereview.chromium.org/2349153004
SkPathEffects must be thread safe, but SkMatrix is only thread safe if
the type mask has already been computed. The constructor for
Sk2DPathEffect is currently making the call to 'invert' which sets the
type mask, but it is being called with the passed matrix as opposed to
the local copy.
BUG=skia:5765
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2340133004
Review-Url: https://codereview.chromium.org/2340133004
For now, we still only have the SkColor factory, but the Descriptor can
now carry either an SkColor or SkColor4f specified gradient. Base class
constructor automatically populates both forms of color, so that legacy
raster backend will continue to work, and new backend work can operate
directly from the float4 version.
On the GPU side, we have similar logic, but GrGradientEffect only
keeps one version of colors around: SkColor if the destination is
legacy, and SkColor4f (with an optional gamut xform) if the destination
is gamma correct. The 4f colors are already linear, and we gamut xform
them in setData, so gradients are now fully color-correct in sRGB and
F16 modes...
... unless there are more than three stops. Then we use a texture, and
that code path isn't handled yet. We have a few choices here (do we
use an 8-bit sRGB atlas, or just always use F16 linear atlas so we can
share it among both sRGB and wide-gamut rendering). In any case, I'd
like to defer that to a second CL.
This change does fix the non-texture gradients in the gamut GM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2337313002
Review-Url: https://codereview.chromium.org/2337313002
Changes the Android shadow sample to use stroked roundrects when
we can (mainly if stroked geometry area < fill geometry area).
Also changes the setup for the overstroke geometry so that it computes
the correct distance to the outer edge.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2283003003
Review-Url: https://codereview.chromium.org/2283003003
This CL does two things:
It fixes the SkBlurMaskFilterImpl::directFilterRRectMaskGPU draw path to explicitly handle rects
It fixes the SkGpuDevice::drawTextureProducerImpl draw path to provide the correct (src & device space) inputs to directFilterRRectMaskGPU.
How this was working before was that GrRRectBlurEffect::Make would reject rect-rrects and the code would fallback to
GrBlurUtils::drawPathWithMaskFilter which mapped the rect-rrect into device space correctly (of course,
the rect-ness of the path was removed at that point so it was going through the slow path).
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2268583002
Review-Url: https://codereview.chromium.org/2268583002
I think we convinced ourselves that denorms, while a good chunk of half floats,
cover a rather small fraction of the representable range, which is always
close enough to zero to flush.
This makes both paths of the conversion to or from float considerably simpler.
These functions now work for zero-or-normal half floats (excluding infinite, NaN).
I'm not aware of a term for this class so I've called them "ordinary".
A handful of GMs and SKPs draw differently in --config f16, but all imperceptibly.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2256023002
Review-Url: https://codereview.chromium.org/2256023002
