Unmarked images should be treated as sRGB.
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4151
Change-Id: I5f8c308d22fd2d069cbfa89c5a5bb19ae6fde8bd
Reviewed-on: https://skia-review.googlesource.com/4151
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This is split out of https://codereview.chromium.org/2215323003/ (Start using RenderTargetProxy (omnibus))
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3841
CQ_INCLUDE_TRYBOTS=master.client.skia.android:Test-Android-Clang-Nexus5-GPU-Adreno330-arm-Debug-GN_Android-Trybot
Change-Id: I1a47f19ed1ac0c249e6ccac8db74095d7f456db4
Reviewed-on: https://skia-review.googlesource.com/3841
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Perhaps these needed to be virtual in the past, but no longer.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4120
Change-Id: I1ba713a1da713f2c7955c0cfc9931917f2719a63
Reviewed-on: https://skia-review.googlesource.com/4120
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
SkMovie is not used in any of our tests or by Chromium. It is also not
supported by GN. It is being moved into Android, its only client, so we
can delete it here.
giflib is only used by SkMovie, so stop pulling/building it.
TBR=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3945
Change-Id: I28a8155fd59e139bb21ec2295cc22fdced034284
Review-Url: https://codereview.chromium.org/2449213004
This is in preparation for GrTextureContext and GrSurfaceContext
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4030
Change-Id: Ie58c93052e68f3f1f5fe8d15d63760de274a6fbd
Reviewed-on: https://skia-review.googlesource.com/4030
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This also makes the required changed to src, tests, and tools. The few
public APIs modified by this change appear to be unused outside of Skia.
Removing these from the public API makes it easier to ensure users are
no longer using them.
This also updates GrGpu::wrapBackendXXX and the
::onWrapBackendXXX methods to clarify ownership.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2448593002
Review-Url: https://codereview.chromium.org/2448593002
The main idea here is to simplify, mainly to reduce the number of SkRasterPipeline objects the blitter holds.
- Use SkBlendMode instead of SkXfermode, just store SkBlendMode.
- Fuse the shader and color filter together into one SkRasterPipeline
during blitter creation.
- I noticed all calls to append_load_d() and append_store() now have the same ctx argument, so I folded that through.
I'll be following up with more of this sort of refactoring... I think I can fold everything into a single SkRasterPipeline during blitter creation now, but I'll want to make sure I've got my ducks in a row for how that works with pipeline strength reduction (like skipping dst loads when drawing in Src mode).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4021
Change-Id: I88252ab8ad16f102c71bad871f8b6aec2fc1f226
Reviewed-on: https://skia-review.googlesource.com/4021
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Many places that construct one are explicitly specifying opaque white or
transparent black, which we can assume (based on the semantics of the
operation) should remain (0,0,0,0) or (1,1,1,1), so that's simple.
In other cases, we convert our source color to destination space.
One wrinkle is tht SkColorFilter now needs to know the destination color
space, due to SkModeColorFilter.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3903
Change-Id: I4969c0260588f4021300733f601b47dc606adf79
Reviewed-on: https://skia-review.googlesource.com/3903
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
There appear to be no existing overriders of the refAs.. method outside
Skia.
Change-Id: Iab174e83023093b4d7fc0bd8907666b66ddb1eea
Reviewed-on: https://skia-review.googlesource.com/3746
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Add an interface to decode frames beyond the first in SkCodec, and
add an implementation for SkGifCodec.
Add getFrameData to SkCodec. This method reads ahead in the stream
to return a vector containing meta data about each frame in the image.
This is not required in order to decode frames beyond the first, but
it allows a client to learn extra information:
- how long the frame should be displayed
- whether a frame should be blended with a prior frame, allowing the
client to provide the prior frame to speed up decoding
Add a new fields to SkCodec::Options:
- fFrameIndex
- fHasPriorFrame
The API is designed so that SkCodec never caches frames. If a
client wants a frame beyond the first, they specify the frame in
Options.fFrameIndex. If the client does not have the
frame's required frame (the frame that this frame must be blended on
top of) cached, they pass false for
Options.fHasPriorFrame. Unless the frame is
independent, the codec will then recursively decode all frames
necessary to decode fFrameIndex. If the client has the required frame
cached, they can put it in the dst they pass to the codec, and the
codec will only draw fFrameIndex onto it.
Replace SkGifCodec's scanline decoding support with progressive
decoding, and update the tests accordingly.
Implement new APIs in SkGifCodec. Instead of using gif_lib, use
GIFImageReader, imported from Chromium (along with its copyright
headers) with the following changes:
- SkGifCodec is now the client
- Replace blink types
- Combine GIFColorMap::buildTable and ::getTable into a method that
creates and returns an SkColorTable
- Input comes from an SkStream, instead of a SegmentReader. Add
SkStreamBuffer, which buffers the (potentially partial) stream in
order to decode progressively.
(FIXME: This requires copying data that previously was read directly
from the SegmentReader. Does this hurt performance? If so, can we
fix it?)
- Remove UMA code
- Instead of reporting screen width and height to the client, allow the
client to query for it
- Fail earlier if the first frame AND screen have size of zero
- Compute required previous frame when adding a new one
- Move GIFParseQuery from GIFImageDecoder to GIFImageReader
- Allow parsing up to a specific frame (to skip parsing the rest of the
stream if a client only wants the first frame)
- Compute whether the first frame has alpha and supports index 8, to
create the SkImageInfo. This happens before reporting that the size
has been decoded.
Add GIFImageDecoder::haveDecodedRow to SkGifCodec, imported from
Chromium (along with its copyright header), with the following changes:
- Add support for sampling
- Use the swizzler
- Keep track of the rows decoded
- Do *not* keep track of whether we've seen alpha
Remove SkCodec::kOutOfOrder_SkScanlineOrder, which was only used by GIF
scanline decoding.
Call onRewind even if there is no stream (SkGifCodec needs to clear its
decoded state so it will decode from the beginning).
Add a method to SkSwizzler to access the offset into the dst, taking
subsetting into account.
Add a GM that animates a GIF.
Add tests for the new APIs.
*** Behavior changes:
* Previously, we reported that an image with a subset frame and no transparent
index was opaque and used the background index (if present) to fill the
background. This is necessary in order to support index 8, but it does not
match viewers/browsers I have seen. Examples:
- Chromium and Gimp render the background transparent
- Firefox, Safari, Linux Image Viewer, Safari Preview clip to the frame (for
a single frame image)
This CL matches Chromium's behavior and renders the background transparent.
This allows us to have consistent behavior across products and simplifies
the code (relative to what we would have to do to continue the old behavior
on Android). It also means that we will no longer support index 8 for some
GIFs.
* Stop checking for GIFSTAMP - all GIFs should be either 89a or 87a.
This matches Chromium. I suspect that bugs would have been reported if valid
GIFs started with "GIFVER" instead of "GIF89a" or "GIF87a" (but did not decode
in Chromium).
*** Future work not included in this CL:
* Move some checks out of haveDecodedRow, since they are the same for the
entire frame e.g.
- intersecting the frameRect with the full image size
- whether there is a color table
* Change when we write transparent pixels
- In some cases, Chromium deemed this unnecessary, but I suspect it is slower
than the fallback case. There will continue to be cases where we should
*not* write them, but for e.g. the first pass where we have already
cleared to transparent (which we may also be able to skip) writing the
transparent pixels will not make anything incorrect.
* Report color type and alpha type per frame
- Depending on alpha values, disposal methods, frame rects, etc, subsequent
frames may have different properties than the first.
* Skip copies of the encoded data
- We copy the encoded data in case the stream is one that cannot be rewound,
so we can parse and then decode (possibly not immediately). For some input
streams, this is unnecessary.
- I was concerned this cause a performance regression, but on average the
new code is faster than the old for the images I tested [1].
- It may cause a performance regression for Chromium, though, where we can
always move back in the stream, so this should be addressed.
Design doc:
https://docs.google.com/a/google.com/document/d/12Qhf9T92MWfdWujQwCIjhCO3sw6pTJB5pJBwDM1T7Kc/
[1] https://docs.google.com/a/google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=2045293002
Review-Url: https://codereview.chromium.org/2045293002
Matches our naming convention for all other types - factories that
return sk_sp (or any type that intelligently manages its own
lifetime) are named Make.
Previous factories are still around, assuming
SK_SUPPORT_LEGACY_COLOR_SPACE_FACTORIES is defined. Enable that
define for Android, etc.
See also: https://codereview.chromium.org/2442053002/
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3822
Change-Id: Iaea9376490736b494e8ffc820831f052bbe1478d
Reviewed-on: https://skia-review.googlesource.com/3822
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
These versions will eliminate lots of copy-pasting in various fragment
processor creation code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3787
Change-Id: I3ada2d4866e92cfc0507beeea11e05790d73757d
Reviewed-on: https://skia-review.googlesource.com/3787
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot;master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN-Trybot
Change-Id: I27a714388b8ded7dfc968e322b0a587205f575f1
Reviewed-on: https://skia-review.googlesource.com/3731
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Even with a modest cache, we're going to get nearly 100% hit rate
for typical usage scenarios. I'm hoping to avoid the special case
caching of sRGB -> destination, and just rely on the more general
mechanism.
Yes, this is yet-another cache class. I wanted to use one of many
that are laying around, but couldn't find a good fit. On the plus
side, it's not much code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3726
Change-Id: I943be5c99f0d691a87ffe8c5bc3067a8eb491fc2
Reviewed-on: https://skia-review.googlesource.com/3726
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
(1) The transformation code *should* support any src SkColorSpace
that we successfully parse. This is agreed upon internally and
by clients. The fact that we currently don't is just a bug...
(2) We cannot and will not support all SkColorSpaces as dsts.
So if we fail to make a SkColorSpaceXform, we should assume that
it was caused by a bad dst color space. The correct response in
this case is to return kInvalidConversion. I've rewritten the CL
to do this.
The fact that weird src spaces will sometimes trigger a
kInvalidConversion is just a bug that is being actively worked on.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3661
Change-Id: Iac2b45120507ec71b1b3d555c61931f7348dad9e
Reviewed-on: https://skia-review.googlesource.com/3661
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Robert Aftias <raftias@google.com>
SkRRectsGaussianEdgeShader will be removed once the usage of the
MaskFilter flavor has been propagated to Android
I will complete the raster implementation in a follow up CL.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3632
Change-Id: I42470b17308582b040a5db1a7283c3d717405345
Reviewed-on: https://skia-review.googlesource.com/3632
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Some classes directly call global operator new to reserve space in
addition to the space the class will occupy. These clases must be
deleted with the unsized global operator new. If a build is configured
such that sized global operator new is called from a delete expression,
this must be overridden by such classes.
TBR=reed
Only affects private bits of SkData.
Change-Id: I797935db17a37aa8c2ca7b562a4ea65a7978a9f0
Reviewed-on: https://skia-review.googlesource.com/3678
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reduces copy-paste and eases maintenance. I'll be adding another field to
AsFPArgs soon, and this is going to streamline that change.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3639
Change-Id: I6372ed5dce50a5ba9d73039bd4714e34502a1f75
Reviewed-on: https://skia-review.googlesource.com/3639
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This also removes the class operator new override along with
directly calling malloc in SkData, since it has a similar requirements.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot;master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN-Trybot
Change-Id: Ic68aacf2028d6964d9735a55558862afc9edd19b
Reviewed-on: https://skia-review.googlesource.com/3541
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Original Commit Message:
"""
Avoid integer overflow in SkIcoCodec
Definitely good to avoid overflow here.
FWIW, this looks to be harmless for Android's current use.
They will just fail later on when trying to allocate the
bitmap.
BUG=skia:5857
"""
With the new test, ASAN also caught an integer overflow
bug in SkImageInfo. Fix this as well.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN;master.client.skia.android:Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android
BUG=skia:5857
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3568
Change-Id: I0d777a547850474ea6cea87e36efa05434e33635
Reviewed-on: https://skia-review.googlesource.com/3568
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Debugger is the last user of the deprecated SkPaintFilterCanvas
constructor. Stop using it and remove the constructor.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3268
Change-Id: I3e9180d48abdf86cb2c05bd8d95acabcdaa70427
Reviewed-on: https://skia-review.googlesource.com/3268
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This tries to match the behavior you would see if you rendered directly to
a canvas without going through this round-trip. Specifically, mips are
built in the same way that they would be according to the context's
internal logic. To make things clearer, the user passes in the color space
of the destination surface, not our (internal) enum.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3526
Change-Id: If8c61500d34ae712227da0284f3a80cacf84113a
Reviewed-on: https://skia-review.googlesource.com/3526
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is only useful in the rare case that the dst does not
fall into one of our main paths.
But it's a good optimization, since this does happen,
and typically, the dst won't change.
ColorCodecBench z620 --nonstd --xform_only
Without Patch 511us
With Patch 348us
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3400
Change-Id: Ibf68d9ce7072680465662922f4aa15630545e3d6
Reviewed-on: https://skia-review.googlesource.com/3400
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This is the last use of kSkiaGamma8888_GrPixelConfig
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3417
Change-Id: I307479c41f1ca437733dfafd044bb1baeb42f31d
Reviewed-on: https://skia-review.googlesource.com/3417
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Necessary because PNGs like to specify their gamma this way.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3402
Change-Id: I399984d611db907b115b345df1afc88d39326fbb
Reviewed-on: https://skia-review.googlesource.com/3402
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
It will now reside in SkColorSpace_Base. Future work for SkColorSpace
will cause this function to not be desirable or sensible to call on
all SkColorSpaces. Call sites were changed to make a kSRGBLinear_Named
instead of kSRGB_Named -> makeLinearGamma() (the majority of cases),
and if that was not possible, SkColorSpace_Base::makeLinearGamma()
was called instead.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2412613005
Review-Url: https://codereview.chromium.org/2412613005
In some legacy situations users of SkRefCnt subclasses were keeping
the objects alive with a reference count of 0. Now that these users are
cleaned up, remove the hack which allowed such code to keep functioning.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3264
Change-Id: I22f63d87b6d995cad6326998284930ad9eaa2983
Reviewed-on: https://skia-review.googlesource.com/3264
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
- perform version check in CreateProc for XfermodeImageFilter and ArithmeticImageFilter
This reverts commit 3ed485f424.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2992
Change-Id: Ib4a154cdd5f5d1dcac921ef50d53b79a2d6a1be8
Reviewed-on: https://skia-review.googlesource.com/2992
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Reason for revert:
Causing problems on Mac & Windows bots.
Original issue's description:
> Make GrResourceCache dynamically change between LRU and random replacement strategies.
>
> Random performs significantly better when each frame exceeds the budget by a small margin whereas LRU has worst case behavior.
>
> The decision of which to use is made based on the history from a few frames of the ratio of total unique key cache misses to unique key cache misses of resources purged in the last 2 frames.
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2321563006
>
> Committed: https://skia.googlesource.com/skia/+/0f147ac2ae575bbad3515a526f13700bc5c8e9d7TBR=bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2386993004
Adds a device space texture decal effect to use for clipping.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2870
Change-Id: Ifcc7617ea87f5a86e301995cba9dfc30a4b0e2c5
Reviewed-on: https://skia-review.googlesource.com/2870
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Random performs significantly better when each frame exceeds the budget by a small margin whereas LRU has worst case behavior.
The decision of which to use is made based on the history from a few frames of the ratio of total unique key cache misses to unique key cache misses of resources purged in the last 2 frames.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2321563006
Review-Url: https://codereview.chromium.org/2321563006
TBR=bsalomon@google.com (Testing-only API change)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2876
Change-Id: I0ca26da0307848cdfc8ffaac2d042601663ab00b
Reviewed-on: https://skia-review.googlesource.com/2876
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Added helper to create random GrColorSpaceXforms in unit tests, and
hooked it up for the FPs that currently accept one.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2873
Change-Id: Iaf93e379e405fbf745f5e0fd23b4daf017355966
Reviewed-on: https://skia-review.googlesource.com/2873
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Currently, Chromium stores segmented data in a SharedBuffer and appends
to SkRWBuffer one segment at a time:
const char* segment = 0;
for (size_t length = data->getSomeData(segment, m_rwBuffer->size());
length; length = data->getSomeData(segment, m_rwBuffer->size())) {
m_rwBuffer->append(segment, length, remaining);
}
This can yield a bunch of just-above-4k allocations => wasted RAM due to
internal fragmentation.
Ideally, we'd want a SkRWBuffer::reserve(size_t bytes) API, but the
current internals don't support that trivially.
Alternatively, the caller can pass a reserve hint at append() time.
BUG=chromium:651698
R=scroggo@google.com,reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2385803002
Review-Url: https://codereview.chromium.org/2385803002
I started fixing more effects and realized I needed something like this.
Wanted to land it separately. After this, I'll add the DC's cached xform
from sRGB to AsFPArgs, so that we can easily leverage this code in more
places (mostly GrConstColorProcessor, or any effect that falls back to
that based on invariants, etc...)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2844
Change-Id: I335546f02a6c49620494d736140a72c14441b35d
Reviewed-on: https://skia-review.googlesource.com/2844
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
In some build configurations (I think, GN, GCC 6, Debug) I get a warning that i is used unintialized. This likely has something to do with GCC correctly seeing that the SkTCast construction there is illegal aliasing, and perhaps thus "doesn't happen". Might be that if the SkTCast gets inlined, it decides its implementation is secretly kosher, and so Release builds don't see this. None of this happens with the GCCs we have on the bots... too old?
Instead use memcpy() here, which is well defined to do what we intended.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2758
Change-Id: Iaf5c75fbd852193b0b861bf5e71450502511d102
Reviewed-on: https://skia-review.googlesource.com/2758
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Added gradient shader factories that take SkColor4f + SkColorSpace.
Modified Descriptor to only store SkColor4f + SkColorSpace.
Existing factories make use of helper code to convert SkColor and
forward to the new factories.
Bumped SKP version to handle new gradient serialization format.
I was toying with using half-float when serializing SkColor4f,
despite my aggressive packing of flags, this format is significantly
bigger.
Also added GM to use 4f factories. This GM should (and does)
look identical to the existing gradients GM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2370063002
Review-Url: https://codereview.chromium.org/2370063002
Gradients (and other shaders) are going to end up serializing this
particular color space very frequently, so we want a shorthand way of
writing it out. I think it's also helpful to have a clearer way of
creating it (vs. NewNamed(kSRGB_Named)->makeLinearGamma()).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2377763002
Review-Url: https://codereview.chromium.org/2377763002
Reason for revert:
Let's see if reverting this helps the roll.
Original issue's description:
> My take on SkAlign changes.
>
> Like the other change, it makes SkAlignN(x) macros work for pointers, and makes the macros themselves just syntax sugar for SkAlign<N>(x). We can still decide if we want to sed away the macros independently.
>
> This just does it in a somewhat less repetitive way, and adds some tests.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368293002
>
> No public API changes.
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/e1a5f4e292384046678edc5c1e360b3e13dc118cTBR=cblume@chromium.org,mtklein@chromium.org
# 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/2372083002
Like the other change, it makes SkAlignN(x) macros work for pointers, and makes the macros themselves just syntax sugar for SkAlign<N>(x). We can still decide if we want to sed away the macros independently.
This just does it in a somewhat less repetitive way, and adds some tests.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368293002
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2368293002
This comes from the Skia fuzzer where it is inverting the RRect's rect which causes trouble down the line.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2591
Change-Id: I5c34105a47369492d2df99d39a4e29116060ad37
Reviewed-on: https://skia-review.googlesource.com/2591
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
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
