skia_ios.mm
Get the app's Documents directory and pass use it to set the resource path.
This is a quick hack which will be replaced by a new application that is
a tiny shim around a command line tool.
SkImageEncoder.h
SkForceLinking.cpp
SkImageDecoder_CG.cpp
Add support for FORCE_LINKING so iOS sees the PNG encoder and others.
SkFloatBits.cpp
SkPoint.cpp
Handle denormalized numbers that are floored by the iOS ARM processor.
SkImageDecoder_iOS.mm
Remove empty encoder factory.
SkTouchGesture.cpp
Return early on empty state on touch rather than aborting (crashing)
JpegTest.cpp
Hal via stackoverflow.com says partial jpegs can be gray as well.
skia_test.cpp
Remove crash handler call for now to avoid link failure.
OverwriteLine.h
Remove fancy line overwrite for iOS.
Resources.cpp
Add interface to set resource directory based on runtime query.
BUG=skia:2736 skia:2737 skia:2738
R=reed@google.com, halcanary@google.com, mtklein@google.com, tfarina@chromium.org
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/373383003
When building acceleration structures for SkPicture, we must transform
the primitive's bounds not only by its own SkPaint, but by the paints of
any saveLayer()s currently active above it.
We do this by pushing the SkPaint onto a stack on
saveLayer(), and popping them on restore(). We also push
a NULL paint in save(), so that the pushes and pops are
balanced.
BUG=skia:2734
R=mtklein@google.com, reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/380373003
Now that all creation of SkImageFilters goes through
factory Create() methods, there's no real reason for the
convenience constructors. Some SkImageFilter subclasses
which actually have zero DAG-able inputs were passing NULL
to the superclass constructor. This actually means 1 input,
with a NULL value, not zero inputs. This becomes more
relevant for the upcoming cache infrastructure, where this
indicates that the filter will use its src input, where in
fact some of these filters do not (they are image generators
only).
Limiting SkImageFilter to a single constructor resolves this
ambiguity.
Along the way, I removed all of the default parameters to
the constructors, since the Create methods always call them
with the full argument list.
BUG=skia:
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/376953003
This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
1) the atlased layers cannot be purged nor aged out
2) the texture backing the atlas is not pulled from (or returned to) the resource cache
#1 is on hold until we have a recycling rectanizer
A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
Committed: https://skia.googlesource.com/skia/+/55e61f0ef4e5c8c34ac107deaadc9b4ffef3111bR=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354533004
Reason for revert:
Sigh
Original issue's description:
> Begin atlasing
>
> This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
>
> 1) the atlased layers cannot be purged nor aged out
> 2) the texture backing the atlas is not pulled from (or returned to) the resource cache
>
> #1 is on hold until we have a recycling rectanizer
>
> A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
>
> Committed: https://skia.googlesource.com/skia/+/55e61f0ef4e5c8c34ac107deaadc9b4ffef3111bR=bsalomon@google.comTBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/359953002
This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
1) the atlased layers cannot be purged nor aged out
2) the texture backing the atlas is not pulled from (or returned to) the resource cache
#1 is on hold until we have a recycling rectanizer
A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354533004
When a RRect is an oval transforming the rectangle and the radii separately can result in a non-oval result (i.e., due to numerical issues some tiny straight edges may creep in). This CL remedies the situation by computing the new radii directly from the transformed rect.
BUG=skia:2696
R=caryclark@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354913004
It is the only file where Test is the prefix rather than the sufix.
This patch fixes that so it matches with the rest of the files
under tests/ directory.
And separate SkISize test into its own DEF_TEST().
BUG=None
TEST=make tests && out/Debug/tests
R=mtklein@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/337783007
- support fRecord in copy constructor
- support SkDrawPictureCallback
Moved SkDrawPictureCallback to its own header so
SkRecordDraw can include it without pulling in all of
SkPicture.
Adding an SkAutoSaveRestore to SkRecordDraw was the easiest
way to match the balance guarantees of the callback, and
probably not a bad idea in general. Updated its tests.
BUG=skia:
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/349973008
Implement path tight bounds using path ops machinery. This is not
as efficient as it could be; for instance, internally, it creates
a path ops structure more suited to intersection. If this shows
up as a performance bottleneck, it could be improved.
Fix path ops gyp files, which have fallen out of sync with other
tests.
R=mtklein@google.com, bsalomon@google.com
TBR=mtklein
BUG=skia:1712
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/348343002
That way when declaring a test with DEF_TEST() macro, you don't have to
uniquify the test name because it might colide with the class it is
being testing.
For example, if you are testing SkBase64 and do:
DEF_TEST(SkBase64, reporter) {
}
That will generate an error because the macro will declare a function
named SkBase64 which colides with the type SkBase64.
By adding Test to the function name we avoid this problem.
Fixed the entries found with the following command line:
$ git grep "Test, r" | grep DEF
BUG=None
TEST=make tests && out/Debug/tests
R=mtklein@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/345753007
This fixes the last bug discovered by iterating through the 800K
skp corpus representing the top 1M websites. For every clip on the
stack, the paths are replaced with the pathop intersection. The
resulting draw is compared with the original draw for pixel errors.
At least two prominent bugs remain. In one, the winding value is
confused by a cubic with an inflection. In the other, a quad/cubic
pair, nearly coincident, fails to find an intersection.
These minor changes include ignoring very tiny self-intersections
of cubics, and processing degenerate edges that don't connect to
anything else.
R=reed@android.com
TBR=reed
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/340103002
The interesting stuff is in SkPictureRecorder.{h,cpp}. The rest is mostly moving SkRecord from its own directories into core to avoid circular dependencies in GYP.
After plumbing SkRecord all the way through in Picture, I'll delete its old entry point include/record/SkRecording.h. For now it and record.gypi need to stay where they are to keep Chrome building.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/331573004
This fixes all but one of those failures.
Major changes include:
- Replace angle indices with angle pointers. This was motivated by the need to add angles later but not renumber existing angles.
- Aggressive segment chase. When the winding is known on a segment, more aggressively passing that winding to adjacent segments allows fragmented data sets to succeed.
- Line segments with ends nearly the same are treated as coincident first.
- Transfer partial coincidence by observing that if segment A is partially coincident to B and C then B and C may be partially coincident.
TBR=reed
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/272153002
This CL improves the separation of the SkPicture and SkPictureRecord classes. It delays creation of the SkPicture (in SkPictureRecorder) until recording is actually completed. To accomplish this the SkRecord-derived classes now get SkPathHeap and SkPictureContentInfo members that are absorbed by the SkPicture when it is constructed.
As an ancillary change, this CL also moves the SkPictureContentInfo object from SkPicture to SkPicturePlayback. This is intended to centralize all the data in the SkPicturePlayback object.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/324293004
The issue is/was that the original Picture/PictureRecorder that is being partially replayed is not guaranteed to issue any more commands before attempting to modify the existing data. Such modification is prohibited if there is a extant copy-on-write snapshot. Rather then further complicate the SkWriter32::snapshot capability for a dis-preferred use case, this CL simply copies the operation data.
R=scroggo@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/316063005
Reason for revert:
Some benchmarks are written in a way that makes this change unsafe (e.g. const char* resPath = GetResourcePath().c_str(); in SkipZeroesBench) and Valgrind and ASAN caught that. We can try again after a more careful cleanup of GetResourcePath().
Original issue's description:
> Clean up resourcePath code.
>
> 1) Make the implementation of SetResourcePath/GetResourcePath of GM and SkBenchmark match with the one in Test.
> 2) Make gResourcePath a static pointer to const char and move it inside the classes.
>
> BUG=None
> TEST=make tests && out/Debug/tests
> make gm && out/Debug/gm
> make bench && out/Debug/bench
> R=mtklein@google.com
>
> Committed: https://skia.googlesource.com/skia/+/52e4f413ffe2d281f9e90ff2147db08083ffcba7R=tfarina@chromium.orgTBR=tfarina@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=None
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/320733002
1) Make the implementation of SetResourcePath/GetResourcePath of GM and SkBenchmark match with the one in Test.
2) Make gResourcePath a static pointer to const char and move it inside the classes.
BUG=None
TEST=make tests && out/Debug/tests
make gm && out/Debug/gm
make bench && out/Debug/bench
R=mtklein@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/319473003
In SkLayerRasterizer::snapshotRasterizer() and ::detachRasterizer(),
if no layers have been added, do not attempt to create an
SkLayerRasterizer. Instead, return NULL.
This fixes an error when running tests on Android.
Update dox to state that NULL may be returned.
Add tests.
R=reed@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/313653006
1 Remove atExit feature: clients can do it just as well as SkOnce can.
2 Remove support for functors: no one but the unit test did that.
3 Remove support for unused non-static SkOnceFlag (no SK_ONCE_INIT).
4 Add SkOnce variants for no-arg functions so we're not forced to pass dummy values all the time.
5 Merge SkSpinlock and SkOnceFlag, making all members private.
6 More notes about memory barriers, adding an acquire load after acquiring the spinlock.
BUG=skia:
R=bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/302083003
Picture serialization is not yet hardened, but it turns out we do need
serialization of SkPictureImageFilter for deferred SVG-on-SVG filters,
since the SkPaints (and thus the SkImageFilters) are serialized by
SkPictureRecord. However, deferred filters are always drawn in the
same process, so we can safely serialize them in this case. We do this
by turning the compile-time check for
SK_ALLOW_PICTUREIMAGEFILTER_SERIALIZATION to a runtime check for
isCrossProcess().
The image filter fuzzer sample was also modified to enable fuzzing
of basic picture image filters (the code had rotted a bit, being behind
an #ifdef that no one sets).
BUG=375162
R=sugoi@google.com
Review URL: https://codereview.chromium.org/311443003
git-svn-id: http://skia.googlecode.com/svn/trunk@15008 2bbb7eff-a529-9590-31e7-b0007b416f81
I'm soon going to have SkRecorder start calling getTotalMatrix(), which
would be broken in write-only mode. That change is big and nebulous,
but it's clear kWriteOnly needs to go, so we might as well kill it now.
My notes in bench_playback about kWriteOnly mode being important were
probably overly cautious. I now think this is a fair enough comparison
even re-recording into a read-write canvas.
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/290653004
git-svn-id: http://skia.googlecode.com/svn/trunk@14963 2bbb7eff-a529-9590-31e7-b0007b416f81
On android trybots, the files in a subdirectory weren't being
loaded onto the device. Consequently, the ImageDecoderOptions
test was not testing anything. I had to relax that unit test
to reflect the existing behavior of our libjpeg decoder on
Android.
R=djsollen@google.com
Review URL: https://codereview.chromium.org/264583007
git-svn-id: http://skia.googlecode.com/svn/trunk@14682 2bbb7eff-a529-9590-31e7-b0007b416f81
The order of arguments in these structs is arbitrary, so we might as well arrange them to optimize something. Putting the paints at the front means the logic to find the paint is a lot more concise: it's usually just ptr+0, or *(ptr+0) when the SkPaint is optional.
This considerably reduces the size of the jump table in IsDraw::operator().
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/272673002
git-svn-id: http://skia.googlecode.com/svn/trunk@14634 2bbb7eff-a529-9590-31e7-b0007b416f81
The cubic line intersection math empirically works 99.99% of the time (fails 3100 out of 1B random tests) but when it fails, an intersection may be missed altogether.
The binary search is may not find a solution if the cubic line failed to find any solutions at all, but so far that case hasn't arisen.
BUG=skia:2504
TBR=reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/266063003
git-svn-id: http://skia.googlecode.com/svn/trunk@14614 2bbb7eff-a529-9590-31e7-b0007b416f81
When verylargebitmap GM runs in cross-process pipe mode, we're
requestBlock()ing ~200M to carry the bitmaps. The current
implementation ends up allocating ~800M, which is a bit wasteful.
SkGPipeWrite already rounds up to 16K, so just rely on that.
This change exposed several bugs in pipe:
- we don't reserve enough space in drawVertices
- we don't reserve enough space for factory names in cross-process mode
- we don't quite have the right check in needOpBytes to see if we needed to send off the current block and allocate a new one
SETUP_NOTIFY and generally calling doNotify() more often than necessary made things hard to debug and understand. Now the pipe always waits to send off its current block until it needs more space than that block can provide, or it's the final block. We can put these back if we need the proactive flushing, but it seems not necessary?
Removed an assert in DeferredCanvasTest, which is somtimes 2 (Debug), sometimes 3 (Release). It seemed like the other asserts were more essential, and this one was more of a white-box assertion. Still sound if we remove it?
BUG=skia:2478
R=scroggo@google.com, mtklein@google.com, reed@google.com, junov@chromium.org
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/267863002
git-svn-id: http://skia.googlecode.com/svn/trunk@14613 2bbb7eff-a529-9590-31e7-b0007b416f81
If an saveLayer()/restore() is recorded, tilegrid/rtree will cull them
out and not draw anything. This is correct for most cases, but if the
paint in the saveLayer() is one that affects transparent black (e.g.,
it contains a color filter or image filter which affects transparent
black), this is incorrect: the filter should be applied.
Fixed by adding a no-op between the saveLayer() and restore(), and
adding a bbox node pointing at that node with the saveLayer()'s bounds.
This exposed a bug in SkPictureRecord.cpp's match(), where it would
assert if the NOOP was the last op seen. Fixed with an early-out before
calling peek_op_and_size().
BUG=skia:2254
Review URL: https://codereview.chromium.org/262363007
git-svn-id: http://skia.googlecode.com/svn/trunk@14604 2bbb7eff-a529-9590-31e7-b0007b416f81
This is a mid-level library for finding patterns of commands in an SkRecord. At the API level, it's a bit regex inspired. Some examples:
- Pattern1<Is<DrawRect>> matches a single DrawRect
- Pattern1<Star<Is<DrawRect>>> matches 0 or more DrawRects
- Pattern2<Is<ClipRect>, Is<DrawRect>> matches a single clip rect followed by a single draw rect
- Pattern3<Is<Save>, Star<IsDraw>, Is<Restore>> matches a single Save, followed by any number of Draws, followed by Restore
- Pattern1<Or<Is<DrawRect>, Is<ClipRect>>> matches a DrawRect or a ClipRect
- Pattern1<Not<Is<ClipRect>>> matches a command that's notClipRect.
Once you have a pattern, you can call .search() on it to step through ranges of matching commands. This means patterns can replace most of the custom iteration logic for optimization passes: the generic pattern searching steps through all the optimization candidates, which optimization-specific code further inspects and mutates.
SkRecordTraits is now unused. Bye bye!
Generated code and performance of SkRecordOpts is very similar to what it was before. (I had to use SK_ALWAYS_INLINE in a few places to make this so.)
BUG=skia:2378
R=fmalita@chromium.org, bungeman@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/263063002
git-svn-id: http://skia.googlecode.com/svn/trunk@14582 2bbb7eff-a529-9590-31e7-b0007b416f81
Before this change, an object needed to inherit from GrResource (and
thus be a GPU object) in order to live in the GrResourceCache. That
was a problem for caching items that weren't GPU objects themselves,
but owned GPU objects.
This change splits GrResource into two classes:
1. GrCacheable: The base class for objects that can live in the
GrResourceCache.
2. GrGpuObject, which inherits from GrCacheable: The base class for
objects that get tracked by GrGpu.
This change is purely a refactor; there is no change in functionality.
Change-Id: I3e8daeb1f123041f414aa306c1366e959ae9e39e
BUG=skia:
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/251013002
git-svn-id: http://skia.googlecode.com/svn/trunk@14553 2bbb7eff-a529-9590-31e7-b0007b416f81
When matrix convolution processes border pixels with zero width, it
asserts in getAddr32() with an invalid x coordinate. The assert is
harmless, since the returned pointer is never accessed (the next line
is a loop from left to right, which does nothing, since left == right).
However, the fix is simple: early out on an empty rect before entering
the outer loop.
R=sugoi@chromium.org
Review URL: https://codereview.chromium.org/265693005
git-svn-id: http://skia.googlecode.com/svn/trunk@14497 2bbb7eff-a529-9590-31e7-b0007b416f81
The old code here wasn't being careful to avoid int32_t overflow in slow_check. Fix that.
R_ASSERT hasn't been doing anything for a while. As a result, there are a couple bugs in SkClampRange, marked as such and commented out. The asserts also weren't quite passing, so I fixed them up (allowing 0xFFFF to be considered either as part of the ramp or part of V1.)
BUG=skia:2481
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/260523004
git-svn-id: http://skia.googlecode.com/svn/trunk@14479 2bbb7eff-a529-9590-31e7-b0007b416f81
On Mike's suggestion, I tested out not doing any empty-clip check at all in
SkRecordDraw, given that mostly we'll do that again anyway inside SkCanvas.
Most SKPs are identical to the status quo, whether bot or silk, played back in tiles
or full. Average playback performance, both arithmetic and geometric mean, is also
unchanged.
A handful of SKPs do draw faster or slower reliably, particularly when tiled. E.g. a
cnn tile draws about 40% faster, a cuteoverload tile about 20% slower. Their profiles
look pretty much the same before and after, so I can't really explain the changes.
I'd say, given that performance is mostly identical and very identical in bulk,
we might as well remove this code. It's nice to keep SkRecordDraw as dumb as possible.
BUG=skia:2378
R=reed@google.com, fmalita@chromium.org, mtklein@google.com, borenet@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/258183002
git-svn-id: http://skia.googlecode.com/svn/trunk@14433 2bbb7eff-a529-9590-31e7-b0007b416f81
Add a new GM that exercises tiled drawing all pixel-moving filters
(and some non-pixel-moving ones) and compares it against non-tiled
drawing of the same filters. Fixing this test revealed that tile and
matrix convolution filters had no onFilterBounds() traversals
(test-driven development FTW). Tile requires (conservatively) the
bounds to include the whole source rect, since it may end up in the
result. Matrix convolution requires the bounds to be offset by the
kernel size and target.
R=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/258243005
git-svn-id: http://skia.googlecode.com/svn/trunk@14432 2bbb7eff-a529-9590-31e7-b0007b416f81
This CL begins the process of making SkPicturePlayback & SkPictureRecord independent of SkPicture. It just moves the PathHeap into SkPicture to get a feel for where all this is going to lead.
Some items of note:
SkTimedPicture (debugger/QT) should wind up being just an SkPicturePlayback-derived object.
All the flattening & unflattening should migrate out of SkPicturePlayback and into SkPicture.
SkPicture::initForPlayback should eventually become something just SkPictureRecorder::endRecording calls.
SkPicture is passed into SkPicturePlayback's & SkPictureRecord's constructors. SkPicturePlayback only
holds onto a "const SkPicture*". The SkPicturePlayback:: CreateFromStream & CreateFromBuffer methods pass a non-const
SkPicture* down the call stack.
BUG=skia:2315
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/249453002
git-svn-id: http://skia.googlecode.com/svn/trunk@14341 2bbb7eff-a529-9590-31e7-b0007b416f81
This adds back two optimizations from SkPicture: drawPosText strength reduction to drawPosTextH, and pointless save-foo-restore blocks are noop'd away.
The small-T optimization in SkRecord gets in the way of implementing replace(), so I removed it.
Just to keep the API focused, I removed the methods on SkRecord that iterate over i for you; it's just as efficient to do it yourself, and all of the interesting code does its own custom iteration.
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/245853002
git-svn-id: http://skia.googlecode.com/svn/trunk@14300 2bbb7eff-a529-9590-31e7-b0007b416f81
This CL sets the stage for retracting the SkPicture::kOptimizeForClippedPlayback_RecordingFlag flag
from the public API (more work needs to be done in Blink & Chrome). In the new world the only way
to set this flag (and thus instantiate an SkPicture-derived
class) is by passing a factory to the SkPictureRecorder class. This is to get all clients always using
factories so that we can then change the factory call used (i.e., so the factory just creates a BBH) and
do away with the SkPicture-derived classes.
BUG=skia:2315
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/239703006
git-svn-id: http://skia.googlecode.com/svn/trunk@14221 2bbb7eff-a529-9590-31e7-b0007b416f81
