SkCodec::NewFromStream claims to delete the passed in SkStream on
failure. This allows the caller to pass an SkStream to the function
and not worry about deleting it depending on the return value.
Most of our SkCodecs did not honor this contract though. Update them
to delete the stream on failure. Further, update SkCodec::NewFromStream
to delete the stream if it did not match any subclass, and delete the
SkCodec if we decided to return NULL because it was too big.
Add a test which tests streams which represent the beginnings of
supported format types but do not contain enough data to create an
SkCodec. The interesting part of the test is when we run it on ASAN,
which will report that we leaked something without the other changes.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1058873006
Add a virtual method on SkStream which will do a "peek" some bytes, so
that those bytes are read, but the next call to read will be
unaffected.
Implement peek for SkMemoryStream, where the implementation is simple
and obvious.
Implement peek on SkFrontBufferedStream.
Add tests.
Motivated by decoding streams which cannot be rewound.
TBR=reed@google.com
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044953002
This mirrors the behavior in onGetPixels, and allows the implementation
to share code for handling calls to rewindIfNeeded.
This also fixes a bug where getScanlineDecoder was calling
rewindIfNeeded and treating the result as a bool.
In SkPngCodec, factor out the code to call rewindIfNeeded, and call it
in both onGetPixels and onGetScanlineDecoder.
Update the test to include testing the scanline decoder. Rename "gen"
to "codec" now that it must be an SkCodec.
BUG=skia:3257
Depends on https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUE).
Review URL: https://codereview.chromium.org/1050893002
Separate out the code for reading the header, and use it to reinitialize
fPng_ptr and fInfo_ptr after a rewind.
Use common code to clean up fPng_ptr and fInfo_ptr, and set them to
NULL and treat them as NULL as appropriate.
Update the test to expect SkPngCodec to succeed.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1048423003
Let's start with baby steps in case some bot can't handle this.
I have left many TODOs, most of which I know how to do if this
looks feasible and useful.
BUG=skia:
Review URL: https://codereview.chromium.org/1049223003
Motivation: Keep separate features separate. Also, future
linearization work will need to have several objNumMap
objects share a substituteMap. Also "catalog" has a
specific meaning in PDF. This catalog did not map to that
catalog.
- Modify SkPDFObject::emitObject and SkPDFObject::addResources
interface to requiore SkPDFObjNumMap and SkPDFSubstituteMap.
- SkPDFObjNumMap const in SkPDFObject::emitObject.
- Remove SkPDFCatalog.cpp/.h
- Modify SkDocument_PDF.cpp to use new functions
- Fold in SkPDFStream::populate
- Fold in SkPDFBitmap::emitDict
- Move SkPDFObjNumMap and SkPDFSubstituteMap to SkPDFTypes.h
- Note (via assert) that SkPDFArray & SkPDFDict don't need to
check substitutes.
- Remove extra space from SkPDFDict serialization.
- SkPDFBitmap SkPDFType0Font SkPDFGraphicState SkPDFStream
updated to new interface.
- PDFPrimitivesTest updated for new interface.
BUG=skia:3585
Review URL: https://codereview.chromium.org/1049753002
The primary feature this delivers is SkNf and SkNd for arbitrary power-of-two N. Non-specialized types or types larger than 128 bits should now Just Work (and we can drop in a specialization to make them faster). Sk4s is now just a typedef for SkNf<4, SkScalar>; Sk4d is SkNf<4, double>, Sk2f SkNf<2, float>, etc.
This also makes implementing new specializations easier and more encapsulated. We're now using template specialization, which means the specialized versions don't have to leak out so much from SkNx_sse.h and SkNx_neon.h.
This design leaves us room to grow up, e.g to SkNf<8, SkScalar> == Sk8s, and to grown down too, to things like SkNi<8, uint16_t> == Sk8h.
To simplify things, I've stripped away most APIs (swizzles, casts, reinterpret_casts) that no one's using yet. I will happily add them back if they seem useful.
You shouldn't feel bad about using any of the typedef Sk4s, Sk4f, Sk4d, Sk2s, Sk2f, Sk2d, Sk4i, etc. Here's how you should feel:
- Sk4f, Sk4s, Sk2d: feel awesome
- Sk2f, Sk2s, Sk4d: feel pretty good
No public API changes.
TBR=reed@google.com
BUG=skia:3592
Review URL: https://codereview.chromium.org/1048593002
Need to land SK_SUPPORT_LEGACY_SCALAR_MAPPOINTS in chrome to suppress Affine
version which causes slight differences (which will need to be rebaselined)
BUG=skia:
Review URL: https://codereview.chromium.org/1045493002
Add and test trunc(), which is what get() used to be before rounding.
Using trunc() is a ~40% speedup on our linear gradient bench.
#neon #floats
BUG=skia:3592
#n5
#n9
CQ_INCLUDE_TRYBOTS=client.skia.android:Test-Android-Nexus5-Adreno330-Arm7-Debug-Trybot;client.skia.android:Test-Android-Nexus9-TegraK1-Arm64-Release-Trybot
Review URL: https://codereview.chromium.org/1032243002
Replace the implicit curve intersection with a geometric curve intersection. The implicit intersection proved mathematically unstable and took a long time to zero in on an answer.
Use pointers instead of indices to refer to parts of curves. Indices required awkward renumbering.
Unify t and point values so that small intervals can be eliminated in one pass.
Break cubics up front to eliminate loops and cusps.
Make the Simplify and Op code more regular and eliminate arbitrary differences.
Add a builder that takes an array of paths and operators.
Delete unused code.
BUG=skia:3588
R=reed@google.com
Review URL: https://codereview.chromium.org/1037573004
There is no reason to require the 4 SkPMFloats (registers) to be adjacent.
The only potential win in loads and stores comes from the SkPMColors being adjacent.
Makes no difference to existing bench.
BUG=skia:
Review URL: https://codereview.chromium.org/1035583002
SkPDFCatalog:
- remove first-page-specific code (no longer needed, never
used) (e.g. addObject()).
- Make use of SkHashMap for lookups (simplifies code).
- inline all small methods
- emitXrefTable moved to SkPDFDocument.cpp
- no longer store offsets in this data structure (moved to
SkPDFDocument.cpp)
- setFileOffset gone.
- own substitute refs directly.
SkPDFDocument::EmitPDF()
- All sites that call into SkPDFCatalog modified.
- catalog.addObject only called in a single place, after the
resouceSet is built
- offsets moved to local array.
SkPDFPage:
- finalizePage no longer deals with SkPDFCatalog or resource sets.
- GeneratePageTree no longer deals with SkPDFCatalog
SkPDFObjRef
- emitObject respects the substitution map
Unit Tests:
- respect SkPDFCatalog::addObject signature change.
SkTHash:
- #include SkChecksum for SkGoodHash
- Copyright notice added
Review URL: https://codereview.chromium.org/1033543002
This seems to fix the miscompilation bug on ARM64 / Release / GCC 4.9.
We switched this over originally for perf issues with NEON, but I can't see any now. Will keep an eye out.
BUG=skia:3570
Review URL: https://codereview.chromium.org/1026403002
SkMatrix::mapPts() using aacc/bbdd was always worse than using badc():
- On Intel, it was faster than exisiting swizzle, but badc() is 10% faster still (one pshufd instead of two).
- On ARM, existing swizzle < badc() < aacc()+bbdd(), even though aacc() then bbdd() is really a single vtrn instruction.
I will revert SkMatrix.cpp before submitting. Just thought you might like to look.
Will think more and try to gear up Instruments on ARM.
BUG=skia:
Review URL: https://codereview.chromium.org/1012573003
This removes all the existing Sk4x swizzles and adds badc(), which is
both fast on all implementations and currently useful.
BUG=skia:
Review URL: https://codereview.chromium.org/997353005
We don't have control over which way _mm_cvtps_epi32 rounds.
- This makes the SSE SkPMFloat rounding consistent with _neon and _none.
- Sk4f::cast<Sk4i>() is closer to (int)float's behavior. (Correct when >=0).
Add tests that would fail at head.
BUG=skia:
Review URL: https://codereview.chromium.org/1029163002
Do not playback pending commands for full deferred canvas writePixels.
Changes the test to catch cases where discard is done without
a snapshot.
Review URL: https://codereview.chromium.org/939103002
- By default, use new SkGoodHash to hash keys, which is:
* for 4 byte values, use SkChecksum::Mix,
* for SkStrings, use SkChecksum::Murmur3 on the data,
* for other structs, shallow hash the struct with Murmur3.
- Expand SkChecksum::Murmur3 to support non-4-byte-aligned data.
- Add const foreach() methods.
- Have foreach() take a functor, which allows lambdas.
BUG=skia:
Review URL: https://codereview.chromium.org/1021033002
The bench improves from 39 to 30, about half from porting to Sk2f, half from
x.add(x) instead of x.multiply(two).
Remove Sk4f Load2/store2 now that we have Sk2f.
BUG=skia:
Review URL: https://codereview.chromium.org/1019773004
(This is essentially a revert of https://codereview.chromium.org/503833002/.)
This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs.
Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.)
BUG=skia:
Review URL: https://codereview.chromium.org/1019493002
malloc_usable_size does not exist in UCLIBC, so fall back to just
returning 0 for SkVarAlloc::heap_size().
BUG=skia:
Review URL: https://codereview.chromium.org/1006073003
SK_BUILD_FOR_WIN is no longer a valid way to check for building on
Windows (go figure). Build everywhere.
Remove the REPORTER_ASSERT, which was the failing part. It also isn't
necessary for the test, which is just that we are not leaking an
SkColorTable.
Also fix indentation.
TBR=bungeman@google.com,mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3457
Review URL: https://codereview.chromium.org/1002583002
Before the fix, we could use a stale cache of the clipbounds in quickReject. Often this could return false negatives, meaning we would try to draw more than we should (it would eventually be really clipped). Occasionally this could also report false positives (if the layer were outside of the normal canvas bounds, e.g. a layer with an offset imagefilter).
BUG=skia:
NOTREECHECKS=True
Review URL: https://codereview.chromium.org/983243003
Clarify asColorFilter ...
1. Rename to isColorFilterNode for DAG reduction
2. Add asAColorFilter for removing the imagefilter entirely (future use-case)
Need layouttest rebaseline suppression before this can land in chrome...
https://codereview.chromium.org/984023004/
BUG=skia:
Review URL: https://codereview.chromium.org/982933002
When computed, the RTree for an SkPicture will have a root
bounds that reflects the best bounding information available,
rather than the best estimate at the time the picture recorder
is created. Given that creators frequently don't know ahead of
time what will be drawn, the RTree bound is often tighter.
Perf testing on Chrome indicates a small raster performance
advantage. For upcoming painting changes in Chrome the
performance advantage is much larger.
BUG=
Committed: https://skia.googlesource.com/skia/+/2dd3b6647dc726f36fd8774b3d0d2e83b493aeac
Review URL: https://codereview.chromium.org/971803002
The tests assert on Sk_ColorGREEN, which is in BRGA non-premul. Read the
pixels in same color format.
Currently the tests pass on all platforms because GREEN is fully opaque
and the component stays in the same place both on BGRA and
RGBA. However, hypothetically somebody could copy-paste the assertion
for further tests but use, say, RED. This creates latent error that is
only visible on some platforms like mac.
Review URL: https://codereview.chromium.org/989463002
Reason for revert:
Need to suppress these for rebaselining, so reverting for now.
Regressions: Unexpected image-only failures (5)
css3/filters/effect-brightness-clamping-hw.html [ ImageOnlyFailure ]
css3/filters/effect-combined-hw.html [ ImageOnlyFailure ]
virtual/slimmingpaint/css3/filters/effect-brightness-clamping-hw.html [ ImageOnlyFailure ]
virtual/slimmingpaint/css3/filters/effect-combined-hw.html [ ImageOnlyFailure ]
Original issue's description:
> Use ComposeColorFilter in factory to collapse consecutive filters (when possible).
> Change asColorFilter to reflect its reliance on the new factory behavior.
>
> patch from issue 967143002 at patchset 80001 (http://crrev.com/967143002#ps80001)
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/dac843bf046c2cd79fd955cb177aee241d7a4b0cTBR=senorblanco@chromium.org,robertphillips@google.com,bsalomon@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/978923005
Reason for revert:
Might be breaking deps roll
Original issue's description:
> Update SkPicture cull rects with RTree information
>
> When computed, the RTree for an SkPicture will have a root
> bounds that reflects the best bounding information available,
> rather than the best estimate at the time the picture recorder
> is created. Given that creators frequently don't know ahead of
> time what will be drawn, the RTree bound is often tighter.
>
> Perf testing on Chrome indicates a small raster performance
> advantage. For upcoming painting changes in Chrome the
> performance advantage is much larger.
>
> BUG=
>
> Committed: https://skia.googlesource.com/skia/+/2dd3b6647dc726f36fd8774b3d0d2e83b493aeacTBR=mtklein@google.com,schenney@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/977413003
Please see if this looks usable. It may even give a perf boost if you use it, even without custom implementations for each instruction set.
I've been trying this morning to beat this naive loop implementation, but so far no luck with either _SSE2.h or _SSSE3.h. It's possible this is an artifact of the microbenchmark, because we're not doing anything between the conversions. I'd like to see how this fits into real code, what assembly's generated, what the hot spots are, etc.
I've updated the tests to test these new APIs, and splintered off a pair of new benchmarks that use the new APIs. This required some minor rejiggering in the benches.
BUG=skia:
Review URL: https://codereview.chromium.org/978213003
When computed, the RTree for an SkPicture will have a root
bounds that reflects the best bounding information available,
rather than the best estimate at the time the picture recorder
is created. Given that creators frequently don't know ahead of
time what will be drawn, the RTree bound is often tighter.
Perf testing on Chrome indicates a small raster performance
advantage. For upcoming painting changes in Chrome the
performance advantage is much larger.
BUG=
Review URL: https://codereview.chromium.org/971803002
Reason for revert:
Fails on mac for some reason.
Also is a bit wrong, but this should not be reason for the failure..
Original issue's description:
> Add image as a draw type that can be filtered
>
> Add image as a draw type that can be filtered.
>
> This is needed when SkImage is added as an object to be drawn so that
> the draw is forwarded to SkBaseDevice. This would be used in making
> filters use SkImages.
>
> BUG=skia:3388
>
> Committed: https://skia.googlesource.com/skia/+/fa77eb1e51b9317ff993d1be504ada173b561e5fTBR=reed@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3388
Review URL: https://codereview.chromium.org/980273002
Add image as a draw type that can be filtered.
This is needed when SkImage is added as an object to be drawn so that
the draw is forwarded to SkBaseDevice. This would be used in making
filters use SkImages.
BUG=skia:3388
Review URL: https://codereview.chromium.org/960783003
Instead of set(SkPMColor), add a constructor SkPMFloat(SkPMColor).
Replace setA(), setR(), etc. with a 4 float constructor.
And, promise to stick to SkPMColor order.
BUG=skia:
Review URL: https://codereview.chromium.org/977773002
SSE rounds for free (that was a happy accident: they also have a truncating version).
NEON does not, nor obviously the portable code, so they add 0.5 before truncating.
NOPRESUBMIT=true
BUG=skia:
Review URL: https://codereview.chromium.org/974643002
This pushes the cost of the *255 and *1/255 conversions onto only those code
paths that need it. We're not doing it any more efficiently than can be done
with Sk4f.
In microbenchmark isolation, this is about a 15% speedup.
BUG=skia:
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/973603002
If a quad, cubic, or conic goes back on itself, assume it's not convex.
In a future CL, we could check to see if the curve is linear so that
linear curves are treated the same as lines.
BUG=skia:3469
Review URL: https://codereview.chromium.org/971773002
Sometimes, the intersection returned by check_intersection() is
out-of-bounds for both edges (above both tops or below both bottoms)
due to floating-point inaccuracy. This causes split_edge() to create a
tiny negative-length edge on one side (which would then assert).
Although we could safely remove this assert and allow the negative
length edge to be removed, it's faster/safer to simply avoid its
creation in the first place by adjusting one edge to the other edge's
endpoint.
Added a new unit test to exercise this case.
Review URL: https://codereview.chromium.org/968993002
- Adds miniz.c v115_r4 (latest release) to third_party.
- Merges SkDeflateWStream into SkFlate so including "miniz.c" links
without duplicating symbols.
The only interesting code change I've made is to remove the line
fImpl->fZStream.data_type = Z_BINARY;
from SkDeflateWStream::SkDeflateWStream(). miniz doesn't have Z_BINARY
defined, and as far as I can tell, both zlib and miniz ignore data_type.
We should be able to swap skflate.gyp's dependency between zlib.gyp:zlib and
zlib.gyp:miniz at will (except of course on Windows) if we're interested in
zlib itself. I've left android framework on its own zlib. I think this all
means we can stop defining SK_NO_FLATE on Windows.
I'll leave the possible cleanup of SK_NO_FLATE itself for another time. Might
be we always want to keep this dependency optional.
CQ_EXTRA_TRYBOTS=client.skia:Test-Win8-ShuttleA-HD7770-x86-Debug-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/957323003
This doesn't add them to the second-stringer Sk4i. It's unclear we should be
doing that often, and we don't have efficient ways to do it except via floats.
BUG=skia:
Review URL: https://codereview.chromium.org/964603002
This path renderer converts paths to linear contours, resolves intersections via Bentley-Ottman, implements a trapezoidal decomposition a la Fournier and Montuno to produce triangles, and renders those with a single draw call. It does not currently do antialiasing, so it must be used in conjunction with multisampling.
A fair amount of the code is to handle floating point edge cases in intersections. Rather than perform exact computations (which would require arbitrary precision arithmetic), we reconnect the mesh to reflect the intersection points. For example, intersections can occur above the current vertex, and force edges to be merged into the current vertex, requiring a restart of the intersections. Splitting edges for intersections can also force them to merge with formerly-distinct edges in the same polygon, or to violate the ordering of the active edge list, or the active edge state of split edges.
BUG=skia:
Review URL: https://codereview.chromium.org/855513004
Fix path bugs exposed by the path fuzzer.
Changes to existing gm and samplecode files defer their calls to construct
SkPath objects until the first draw instead of at test initialization.
Add an experimental call to SkPath to validate the internal SkPathRef.
Fix SkPath::addPoly to set the last moveto after adding a close verb.
Fix stroke to handle failures when computing the unit normal.
Add a unit test for the unit normal failure.
R=reed@google.com
Review URL: https://codereview.chromium.org/953383002
Without this patch the iterator can end up running off the end of the conic weights if there is a mixture of degenerate and non-degenerate ops
Note: we might want to suppress the generation of degenerate conics and lines in SkPath::addRRect
BUG=459897
Review URL: https://codereview.chromium.org/954453003
Plumb SkDOM as needed to make it suitable for an SkXMLWriter backend.
Also fix a potential null typeface issue in
SkSVGDevice::AutoElement::addTextAttributes().
R=reed@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/940283002
I've written some new hashtable interfaces that should be easier to use,
and I've been trying to roll them out bit by bit, hopefully replacing
SkTDynamicHash, SkTMultiMap, SkTHashCache, etc.
This turns the cache in GrGLCaps::readPixelsSupported() into an SkTHashMap,
mapping the format key to a bool. Functionally, it's the same.
BUG=skia:
Review URL: https://codereview.chromium.org/948473002
Replace the old signature of onGetPixels (return bool) to return an
enum (Result). Remove onGetPixelsEnum.
Add a define for onGetPixelsEnum to onGetPixels. This is for staging
in Chromium, where some implementations override onGetPixelsEnum.
Add the define in skia_for_chromium_defines. Remove
SK_SUPPORT_LEGACY_IMAGE_GENERATOR_RETURN, which is no longer needed by
Chromium.
BUG=skia:3257
Review URL: https://codereview.chromium.org/939113002
Use the form SkDebugf("%s", arbitraryString) instead of
SkDebugf(arbitraryString).
Fixes the case where SkString::appendf-ing a string with "%%" and then
printing the string with SkDebugf would cause uninitialized read and
corrupted debug print.
ninja -C out/Debug tools && valgrind --leak-check=full
./out/Debug/render_pictures --config gpu -w q -r ...
...
==7307== Conditional jump or move depends on uninitialised value(s)
==7307== at 0x6908475: __printf_fp (printf_fp.c:1180)
==7307== by 0x6904267: vfprintf (vfprintf.c:1629)
==7307== by 0x6906E53: buffered_vfprintf (vfprintf.c:2313)
==7307== by 0x690188D: vfprintf (vfprintf.c:1316)
==7307== by 0x67E8F5: SkDebugf(char const*, ...) (SkDebug_stdio.cpp:18)
==7307== by 0x7983F1: GrContext::printCacheStats() const (GrTest.cpp:54)
==7307== by 0x408ECF: tool_main(int, char**) (render_pictures_main.cpp:480)
==7307== by 0x40913E: main (render_pictures_main.cpp:511)
==7307==
Budget: 2048 items 100663296 bytes
Entry Count: current 652 (651 budgeted, 0 wrapped, 297 locked, 638 scratch 32 0.000000ull), high 652
Entry Bytes: current 51087658 (budgeted 49826658, 49 0.000000ull, 1261000 unbudgeted) high 51087658
(observe "ull" instead of "% full")
(from mtklein)
This CL is not editing public API.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/943453002
Also: Add SkDeflateWStream and associated unit tests.
SkPDFBitmap is a replacement for SkPDFImage. As of now, it only
supports 8888 bitmaps (the most common case).
SkPDFBitmap takes very little extra memory (aside from refing the
bitmap's pixels), and its emitObject() does not cache any data.
The SkPDFBitmap::Create function will check the canon for duplicates.
This can reduce the size of the output PDF.
Motivation: this gives another ~40% decrease in PDF memory overhead
TODO: Support other ColorTypes and scrap SkPDFImage.
BUG=skia:3030
Review URL: https://codereview.chromium.org/918813002
