These tests were isolated from their respective minimized test cases.
The tests work fine and pass path ops internal validation;
hopefully some more intensive x-san or valgrind test will help
isolate the bug.
Sheriff, please revert if it fails and I don't get to it first.
TBR=reed@google.com,halcanary@google.com
BUG=535127,535151
Review URL: https://codereview.chromium.org/1359263003
The last parameter of CTFontCreateWithGraphicsFont (CTFontDescriptorRef
attributes) *must* be nullptr. If non-nullptr then with fonts with
variation axes, the copy will fail in CGFontVariationFromDictCallback
when it assumes kCGFontVariationAxisName is CFNumberRef which it quite
obviously is not.
TBR=reed@google.com
Blocking dev builds, just removes code.
BUG=chromium:535109
Review URL: https://codereview.chromium.org/1362053003
Motivation: I want too finalize this API before working on the more
complex problem of adding XMP metadata for PDF/A.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1359943003
Compare Ganesh and HWUI canvas rendering of SKPs on android.
Put SKP files in .../canvasproof/src/main/assets/skps
Run on a Marshmallow device.
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1258123004
SkBitmapRegionDecoderInterface provides an interface
for multiple implementations of Android's
BitmapRegionDecoder.
We already have correctness tests in DM that will enable us
to compare the quality of our various BRD implementations.
We also need these performance tests to compare the speed
of our various implementations.
BUG=skia:4357
Review URL: https://codereview.chromium.org/1344993003
It appears that CTFontCreateCopyWithAttributes and
CTFontCreateCopyWithSymbolicTraits share similar issues with the default
font on OSX10.10. CTFontCreateWithFontDescriptor cannot be used as
it will not work with webfonts. Since this is all low-level use, create the
CTFonts from the underlying CGFonts directly.
BUG=chromium:524646
Committed: https://skia.googlesource.com/skia/+/d3296717b9d0930237be3502b82ab94d0b4d177f
Review URL: https://codereview.chromium.org/1344213004
This CL removes the uses of SkNEW that have resprouted since commit
385fe4d, and removes the macros entirely now that Android and Chromium
have been cleaned up to no longer depend on them.
A bunch of files implicitly depend on #include <new> from SkPostConfig.h
still though, so keep that for now. To be fixed in a followup CL.
[mtklein mucking around]
Only public API removed.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1360653004
Reason for revert:
Who wants to land forever?
Original issue's description:
> update memset16/32 inlining heuristics
>
> I spent some time looking at perf.skia.org and it looks like we can do better.
>
> It is weird, weird, weird that on x86, we see three completely different behaviors:
> - x86 Android: inlining better for small N, custom better for large N;
> - Windows: inlining better for large N, custom better for small N;
> - other x86: inlining generally better
>
> BUG=skia:4316,chromium:516426
>
> (Temporary, plan to revert.)
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/b68fa409fc00ce2f38e2a0fd6f9dc2379b372481TBR=reed@google.com,jcgregorio@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4316,chromium:516426
Review URL: https://codereview.chromium.org/1358793002
I spent some time looking at perf.skia.org and it looks like we can do better.
It is weird, weird, weird that on x86, we see three completely different behaviors:
- x86 Android: inlining better for small N, custom better for large N;
- Windows: inlining better for large N, custom better for small N;
- other x86: inlining generally better
BUG=skia:4316,chromium:516426
(Temporary, plan to revert.)
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1357193002
