This reverts commit c73a1ecbed.
Reason for revert: ANGLE and CommandBuffer failures
Original change's description:
> Support decoding images to multiple formats, depending on usage
>
> Our codec generator will now preserve any asked-for color space, and
> convert the encoded data to that representation. Cacherator now
> allows decoding an image to both legacy (nullptr color space), and
> color-correct formats. In color-correct mode, we choose the best
> decoded format, based on the original properties, and our backend's
> capabilities. Preference is given to the native format, when it's
> already texturable (sRGB 8888 or F16 linear). Otherwise, we prefer
> linear F16, and fall back to sRGB when that's not an option.
>
> BUG=skia:5907
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4438
>
> Change-Id: I847c243dcfb72d8c0f1f6fc73c09547adea933f0
> Reviewed-on: https://skia-review.googlesource.com/4438
> Reviewed-by: Matt Sarett <msarett@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
>
TBR=mtklein@google.com,bsalomon@google.com,msarett@google.com,brianosman@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I1818f937464573d601f64e5a1f1eb43f5a778f4e
Reviewed-on: https://skia-review.googlesource.com/4832
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Our codec generator will now preserve any asked-for color space, and
convert the encoded data to that representation. Cacherator now
allows decoding an image to both legacy (nullptr color space), and
color-correct formats. In color-correct mode, we choose the best
decoded format, based on the original properties, and our backend's
capabilities. Preference is given to the native format, when it's
already texturable (sRGB 8888 or F16 linear). Otherwise, we prefer
linear F16, and fall back to sRGB when that's not an option.
BUG=skia:5907
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4438
Change-Id: I847c243dcfb72d8c0f1f6fc73c09547adea933f0
Reviewed-on: https://skia-review.googlesource.com/4438
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Use anisotropic scale to show bug in verylargebitmap test.
BUG=chromium:664615
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4774
Change-Id: If92eab6d26b9fb506670412a80df259f99db2a21
Reviewed-on: https://skia-review.googlesource.com/4774
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
There is support for all features of SkColorSpace_A2B.
Tests for these functionality were adapted from
the XYZ xform, plus a CLUT-specific test was added.
Shared functions used by both SkColorSpaceXform_XYZ and SkColorSpaceXform_A2B
have been moved into a shared header.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2449243003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2449243003
This reverts commit 8240750718.
Reason for revert: Breaking WebView (chromium:663959)
Original change's description:
> Change SkCanvas to *not* inherit from SkRefCnt
>
> Definitely tricky for classes like SkNWayCanvas, where the caller (today)
> need not pay attention to ownership of the canvases it gave the NWay
> (after this CL, the caller *must* managed ownership)
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4441
>
> DOCS_PREVIEW= https://skia.org/?cl=4441
>
> Change-Id: Ib1ac07a3cdf0686d78e7aaa4735d45cc90bea081
> Reviewed-on: https://skia-review.googlesource.com/4441
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
>
TBR=djsollen@google.com,mtklein@google.com,halcanary@google.com,robertphillips@google.com,fmalita@chromium.org,fmalita@google.com,reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I5e3b3e876b7d2c09833cf841801321033b6b968b
Reviewed-on: https://skia-review.googlesource.com/4687
Commit-Queue: Heather Miller <hcm@google.com>
Reviewed-by: Heather Miller <hcm@google.com>
Definitely tricky for classes like SkNWayCanvas, where the caller (today)
need not pay attention to ownership of the canvases it gave the NWay
(after this CL, the caller *must* managed ownership)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4441
DOCS_PREVIEW= https://skia.org/?cl=4441
Change-Id: Ib1ac07a3cdf0686d78e7aaa4735d45cc90bea081
Reviewed-on: https://skia-review.googlesource.com/4441
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This removes a reason to call accessRenderTarget on the GrRenderTargetContext
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4583
Change-Id: I6e8a53ffd5c1fea80f542b70e05744e2991f70f8
Reviewed-on: https://skia-review.googlesource.com/4583
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This is much more explicit about what that type represents (are we in
legacy mode or not), which also makes it suitable for other (upcoming)
usage.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4529
Change-Id: Iacb397c34e7765f1ca86c0195bc622b2be4d9acf
Reviewed-on: https://skia-review.googlesource.com/4529
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit e48b4c550d.
Reason for revert: This method is used in Google3. See
https://test.corp.google.com/ui#id=OCL:138505330:BASE:138505351:1478611655214:39a02f0d
Original change's description:
> Delete SkImage::encode(Type)
>
> This doesn't appear to be used (fingers crossed).
>
> We're not ready to support color correct encodes (and tagging with
> color spaces) for all of the formats included in SkImageEncoder::Type.
>
> I think it's good to restrict this for now.
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4535
>
> Change-Id: I73000f3d7bff1af153786d766531a2cbc8c5b77a
> Reviewed-on: https://skia-review.googlesource.com/4535
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Matt Sarett <msarett@google.com>
>
TBR=msarett@google.com,brianosman@google.com,reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I6fb880f10dcba7837647e9b5cabbc8cc2b8366f6
Reviewed-on: https://skia-review.googlesource.com/4538
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
This doesn't appear to be used (fingers crossed).
We're not ready to support color correct encodes (and tagging with
color spaces) for all of the formats included in SkImageEncoder::Type.
I think it's good to restrict this for now.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4535
Change-Id: I73000f3d7bff1af153786d766531a2cbc8c5b77a
Reviewed-on: https://skia-review.googlesource.com/4535
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
If not, we sometimes would end up with only one edge for a convex path. That
either triggers SkASSERT(count >= 2) failure in debug build or SIGSEGV in
release build. After the change, we should return 0 edges for such a path
because everything is totally combined.
Note that this change also makes the SkAnalyticEdge's CombineVertical function
behave more similarly to SkEdge's CombineVertical function: SkEdge only
compares fFirstY and fLastY which are integer values, which is equivalent to
setting our tolerance to SK_Fixed1 (our current tolerance is 0x100, 1/256 of
SK_Fixed1). And this is intentional.
BUG=chrome:662914
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2477373002
Review-Url: https://codereview.chromium.org/2477373002
Replace with std::unique_ptr.
Change-Id: I5806cfbb30515fcb20e5e66ce13fb5f3b8728176
Reviewed-on: https://skia-review.googlesource.com/4381
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
When downscaling with kMediumQuality in non-clamp mode, if we happen to hit a size == mip level, then SkBitmapProcInfo::init takes the trivial matrix path and doesn't set up a matrix for normalized coords on the assumption that we're going to ignore the transform. But kMediumQuality disables allow_ignore_fractional_translate, so we take the filter path after all - but with an incorrect matrix.
R=reed@google.com
BUG=chromium:661180
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2476713002
Review-Url: https://codereview.chromium.org/2476713002
This class is already just an alias for std::unique_ptr<T[]>, so replace
all uses with that and delete the class.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot,Test-Ubuntu-Clang-Golo-GPU-GT610-x86_64-Debug-ASAN-Trybot
Change-Id: I40668d398356a22da071ee791666c7f728b59266
Reviewed-on: https://skia-review.googlesource.com/4362
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This makes the behavior match our gpu backend.
BUG=android:31019366
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3979
Change-Id: I941623d0bdf54f61aafb1383de46bbedceb7578d
Reviewed-on: https://skia-review.googlesource.com/3979
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
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
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>
This is essential for representing non-lutAtoBType A2B tags such as
lut16Type, lut8Type, mpet. Parsing of A2B0 tags was also moved ahead
of the TRC/XYZ-matrix parsing, as profiles examined with both tags
either had the TRC/XYZ tags as a fall-back or were incorrectly displayed
if only the TRC/XYZ tags were used.
This was submitted alone to reduce CL size. Tests that will use these changes will be introduced in the subsequent CLs that add on lut8/16Type A2B0 parsing. We already have lut16Type test images and these have been tested locally, but require additional code not submitted yet for lut16Type ICC profile parsing and A2B colorspace xforms.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2444553002
Review-Url: https://codereview.chromium.org/2444553002
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>
The bug was the raster version didn't correctly handle the CTM.
This CL also adds a way to test the behavior (by translating the
reveal GM around in SampleApp)
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3729
Change-Id: Iaacc905167d20b453203307e5ef840f552fdbb38
Reviewed-on: https://skia-review.googlesource.com/3729
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@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>
In this function, when count is 0, it maps the dst point to start, where
it should really be stop. A test case is also added.
In the test case, it should be drawing three lines, without the change in
SkPath class, it will draw 2 lines only with the top horizontal line
missing because it maps the dst point to the start point, and hence
the horizontal line is not drawn.
BUG=640031
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2409983004
Review-Url: https://chromiumcodereview.appspot.com/2409983004
The refactoring breaks off A2B0 tag support into a separate
subclass of SkColorSpace_Base, while keeping the current
(besides CLUT) functionality in a XYZTRC subclass.
ICC profile loading is now aware of this and creates the A2B0
subclass when SkColorSpace::NewICC() is called on a profile
in need of the A2B0 functionality.
The LabPCSDemo GM loads a .icc profile containing a LAB PCS and
then runs a Lab->XYZ conversion on an image using it so we can
display it and test out the A2B0 SkColorSpace functionality,
sans a/b/m-curves, as well as the Lab->XYZ conversion code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2389983002
Review-Url: https://codereview.chromium.org/2389983002
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>
With this CL we handle single off-center hardstop gradients.
BUG=chromium:543625
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3303
Change-Id: Ic754e87469475ce15865c54055b8ed492e1d826d
Reviewed-on: https://skia-review.googlesource.com/3303
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Osman <brianosman@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
This would've caught the incorrect distances in the center bug
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3111
Change-Id: I9461a8865b561cc139a18a5e779e933d7979ee0d
Reviewed-on: https://skia-review.googlesource.com/3111
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
In this function, it first check whether this arc is a lone point
or not. If not, it converts angles to unit vectors. The problem
here is that when the radius is huge and the sweepAngle is small,
the function angles_to_unit_vectors() could return a startV ==stopV.
When that happens, it will draw a dot at the point that corresponding
to the startAngle. This CL adds a special branch for this case, and
draw a connecting line between the points at startAngle and endAngle.
BUG=640031, skia:5807
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2388833002
Review-Url: https://codereview.chromium.org/2388833002
- 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>
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>
Fix imagealphathreshold_surface GM to test gamut conversion.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2867
Change-Id: Id9aaebe72d1dadc613ef1a8d17d066b51049300f
Reviewed-on: https://skia-review.googlesource.com/2867
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@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:
Hitting an assert
Original issue's description:
> Support Float32 output from SkColorSpaceXform
>
> * Adds Float32 support to SkColorSpaceXform
> * Changes API to allows clients to ask for F32, updates clients to
> new API
> * Adds Sk4f_load4 and Sk4f_store4 to SkNx
> * Make use of new xform in SkGr.cpp
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339233003
> CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/43d6651111374b5d1e4ddd9030dcf079b448ec47TBR=brianosman@google.com,mtklein@google.com,scroggo@google.com,mtklein@chromium.org,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/2347473007
* Adds Float32 support to SkColorSpaceXform
* Changes API to allows clients to ask for F32, updates clients to
new API
* Adds Sk4f_load4 and Sk4f_store4 to SkNx
* Make use of new xform in SkGr.cpp
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339233003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2339233003
This is a step towards using SkCodec in Chromium, where progressive
decoding is necessary.
Switch from using png_read_row (which expects all the data to be
available) to png_process_data, which uses callbacks when rows are
available.
Create a new API for SkCodec, which supports progressive decoding and
scanline decoding. Future changes will switch the other clients off of
startScanlineDecode and get/skip-Scanlines to the new API.
Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
updateCurrScanline(), which was only used by the old implementation for
interlaced PNG.
DMSrcSink:
- In CodecSrc::kScanline_Mode, use the new method for scanline decoding
for the supported formats (just PNG and PNG-in-ICO for now).
fuzz.cpp:
- Remove reference to kNone_ScanlineOrder
SkCodec:
- Add new APIs:
- startIncrementalDecode
- incrementalDecode
- Remove kNone_SkScanlineOrder and updateCurrScanline()
- Set fDstInfo and fOptions in getPixels(). This may not be necessary
for all implementations, but it simplifies things for SkPngCodec.
SkPngCodec:
- Implement new APIs
- Switch from sk_read_fn/png_read_row etc to png_process_data
- Expand AutoCleanPng's role to decode the header and create the
SkPngCodec
- Make the interlaced PNG decoder report how many lines were
initialized during an incomplete decode
SkIcoCodec:
- Implement the new APIs; supported for PNG in ICO
SkSampledCodec:
- Call the new method for decoding scanlines, and fall back to the old
method if the new version is unimplemented
- Remove references to kNone_SkScanlineOrder
tests/CodecPartial:
- Add a test which decodes part of an image, then finishes the decode,
and compares it to the straightforward method
tests/CodecTest:
- Add a test which decodes all scanlines using the new method
- Repurpose the Codec_stripes test to decode using the new method in
sections rather than all at once
- In the method check(), add a parameter for whether the image supports
the new method of scanline decoding, and be explicit about whether an
image supports incomplete
- Test incomplete PNG decodes. We should have been doing it anyway for
non-interlaced (except for an image that is too small - one row), but
the new method supports interlaced incomplete as well
- Make test_invalid_parameters test the new method
- Add a test to ensure that it's safe to fall back to scanline decoding without
rewinding
BUG=skia:4211
The new version was generally faster than the old version (but not significantly so).
Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
Review-Url: https://codereview.chromium.org/1997703003
We were effectively storing the transpose, which made all of our
operations on individual colors, and our concatenation of matrices
awkward and backwards.
I'm planning to push this further into Ganesh, where I had incorrectly
adjusted to the previous layout, treating colors as row vectors in the
shaders.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2324843003
Review-Url: https://codereview.chromium.org/2324843003
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
HWUI skips transparent rects when drawing.
When skia draws using bilerp, we will blend
transparent rects with neighboring rects and might
draw a bit of a smudge.
This CL adds the option to skip rects, allowing us
to have compatible behavior with the framework.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2305433002
Review-Url: https://codereview.chromium.org/2305433002
'static const' means, there must be at most one of these, and initialize it at
compile time if possible or runtime if necessary. This leads to unexpected
code execution, and TSAN* will complain about races on the guard variables.
Generally 'constexpr' or 'const' are better choices. Neither can cause races:
they're either intialized at compile time (constexpr) or intialized each time
independently (const).
This CL prefers constexpr where possible, and uses const where not. It even
prefers constexpr over const where they don't make a difference... I want to have
lots of examples of constexpr for people to see and mimic.
The scoped-to-class static has nothing to do with any of this, and is not changed.
* Not yet on the bots, which use an older TSAN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300623005
Review-Url: https://codereview.chromium.org/2300623005
- Switch to portable typeface, to avoid per-platform diffs in the labels
- Stretch out the image slightly, to avoid overlap with larger font
- Fix several tests that were no longer matching ground-truth. We treat
SkColor as sRGB, so 0x7F is incorrect, for example. Several of the
XferMode tests had similar math errors now. Computed new values, and
verified that they work as expected.
- Removed a couple tests that were mixing color and alpha in funny ways
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2288053003
Review-Url: https://codereview.chromium.org/2288053003
Verify the rules that we're converging on for surfaces:
- For 8888, we only support sRGB-like gamma, or no color space at all.
- For F16, we require a color space, with linear gamma.
- For all other formats, we do not support color spaces.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2270823002
Review-Url: https://codereview.chromium.org/2270823002
This seems to work well for miter and bevel joins with the resulting stroke and fill path remaining convex. There seems to be an issue with round joins where the outer generated shell is usually not convex. Without this CL the resulting stroke & filled paths are always concave.
Perf-wise (on Windows):
convex-lineonly-paths-stroke-and-fill bench
(in ms) w/o w/CL %decrease
8888 2.88 2.01 30.2
gpu 4.4 1.38 68.6
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275243003
Review-Url: https://codereview.chromium.org/2275243003
Keep isOpaque as a convenience method -- many places really only need to
know that for optimization purposes (SrcOver -> Src, etc...).
In all the places where we pull data back out or convert to another
object and need to supply an SkImageInfo, we can avoid losing information
about premulness.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2250663002
Review-Url: https://codereview.chromium.org/2250663002
Reason for revert:
Broken Windows bot.
Original issue's description:
> Fix WIC encoder to support kJPEG_Type
>
> (1) Add support for kJPEG to WIC
> (2) Add encoding test.
> (3) Turn on WIC jpeg encoder on Windows and CG jpeg
> encoder on Mac.
>
> A follow-up may make Skia's encoders the default on all
> platforms. But, in order to do that, I think we need
> to write better encoding unit tests for CG and WIC.
>
> BUG=skia:3969
> BUG=skia:5632
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2245453002
>
> Committed: https://skia.googlesource.com/skia/+/b3a7ef1fc0adc24859d2498aee54d3ec2cbcac3aTBR=mtklein@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3969
Review-Url: https://codereview.chromium.org/2246203002
(1) Add support for kJPEG to WIC
(2) Add encoding test.
(3) Turn on WIC jpeg encoder on Windows and CG jpeg
encoder on Mac.
A follow-up may make Skia's encoders the default on all
platforms. But, in order to do that, I think we need
to write better encoding unit tests for CG and WIC.
BUG=skia:3969
BUG=skia:5632
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2245453002
Review-Url: https://codereview.chromium.org/2245453002
