Reason for revert:
Killing Mac
Original issue's description:
> SkFontData to use smart pointers.
>
> The SkFontData type is not exposed externally, so any method which uses
> it can be updated to use smart pointers without affecting external
> users. Updating this first will make updating the public API much
> easier.
>
> This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
> std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
> appears that no one outside Skia is currently using SkStream::NewfromFile
> so this is a good time to update it as well.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
>
> Committed: https://skia.googlesource.com/skia/+/d8c2476a8b1e1e1a1771b17e8dd4db8645914f8cTBR=mtklein@chromium.org,halcanary@google.com,mtklein@google.com,reed@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/2343933002
The SkFontData type is not exposed externally, so any method which uses
it can be updated to use smart pointers without affecting external
users. Updating this first will make updating the public API much
easier.
This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
appears that no one outside Skia is currently using SkStream::NewfromFile
so this is a good time to update it as well.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
Review-Url: https://codereview.chromium.org/2339273002
If a quad a conic intersect only where the end of one
is contained by the convex hull of the other, and the
curve contained by the hull is nearly a straight line,
treating it as a line may move the end point to the
other side of the curve.
Detect this by checking to see if the end point is in
the hull, and if so, continue to subdivide the curve
rather than treating it as a line.
This fixes several existing tests that were disabled
earlier this year.
A typo in SkDCurve::nearPoint() prevented detecting when
the end of a line was nearly touching a curve.
Also fixed concidence a bit to get the second half of
tiger further along.
All existing tests, including extended testing in
Release and the first half of tiger, work.
TBR=reed@google.com
BUG=skia:5131
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2338323002
Review-Url: https://codereview.chromium.org/2338323002
- swap the N5 experiment over to the new GN N5 bot
- cut down on the Windows build duplication: the other two bots
cover x86, x86-64, Release, Debug, _and_ Vulkan already.
- remove the Release-Shared tester: I added this bot to act as a proxy
for the also Shared-build Android bots, but 1) they're fast enough
to no longer need a proxy (see N5 above) and 2) they're no longer
Shared builds. I intend to completely drop support for dm and
nanobench in Shared builds, so this bot will not just drop from the
CQ but completely disappear.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2346463002
Review-Url: https://codereview.chromium.org/2346463002
... and use it to control debug symbols and SK_ALLOW_STATIC_GLOBAL_INITIALIZERS.
This will most directly have the effect of disabling GLProgramsTest and a bunch
of similar failing Vk tests on Android.
Hopefully this makes the N7 trybot go green, keeping the N5 trybot green. Just running the N10 for fun.
(is_official_build is how Chrome terms this sort of ReleaseForReal build.)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2340723003
Review-Url: https://codereview.chromium.org/2340723003
In order of likelihood:
(1) Tables are never used, since gamma is recognized and named.
(2) Only use one table, since all three gammas are the same.
(3) Actually need three tables.
No reason to waste a bunch of space for these tables on
SkColorSpaceXform, when it will likely be unused.
This will be more efficient in lots of cases, but is particularly
useful when the client really only wants a gamut xform.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2336913005
Review-Url: https://codereview.chromium.org/2336913005
The path writer takes constructs the output path out of
curves that satisfy the pathop operation.
Curves contain lists of t/point pairs that may not be
comparable to each other. To match up curve ends in the
output path, look for adjacent curves to have a shared
membership rather than comparing point values.
Use path utilities to connect partial curve lists into
closed contours.
Share the angle code that determines if a curve has become
a degenerate line with the path writer.
Clean up some code on the way, and delete some unused
functions.
TBR=reed@google.com
BUG=5188
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2321973005
Review-Url: https://codereview.chromium.org/2321973005
We used to build src and dst transfer fn tables
every time a new xform was created with linear
src and dst. Now we don't compute them because
we don't need them.
This will make SkColorSpaceXform a far better
option for any xforms with float or half-float
inputs or outputs, particularly on a small number
of pixels.
This CL also moves SkColorSpaceXform closer to
what I anticipate will be the eventual 'API design'.
I think apply() will want to take a SrcColorType enum
(not created yet because it's not necessary yet) and
a DstColorType enum (still using SkColorType because
there's not yet a reason not to).
Performance changes:
toSRGB 341us -> 366us
to2Dot2 404us -> 403us
toF16 318us -> 304us
There's no reason for toSRGB or to2Dot2 to change.
The refactor seems to have caused the compiler to
order the instructions a little differently...
This is something to come back to if we need to
squeeze more performance out of sRGB. For now,
let's not be held up by something we don't control.
F16 likely improves because we are no longer
(unnecessarily) building the linear tables.
Code size gets a little bigger. Measuring
SkColorSpaceXform size as a percentage of src/ size,
we go from 0.8% to 1.4%.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2335723002
Review-Url: https://codereview.chromium.org/2335723002
Android's the easiest place to start supporting Vulkan, so it's up first.
ndk_api becomes user-specifiable so that the Vulkan bots can kick it up
to 24, the first release supporting Vulkan. The defaults remain the same:
18 for 32-bit and 21 for 64-bit, the first release supporting 64-bit.
To test this, I set ndk_api=24 and skia_use_vulkan=true in GN, then
$ ninja -C out dm; and droid out/dm --config vk --src gm
Seems to work! Bot scripts to follow.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2336343002
Review-Url: https://codereview.chromium.org/2336343002
Some font back-ends provide simulated fonts such as fake bold or fake
oblique. These fonts should not be reported as TrueType, since the font
data isn't what is actually used to draw the glyphs.
BUG=chromium:639198
BUG=chromium:614612
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2333423002
Review-Url: https://codereview.chromium.org/2333423002
These were intended to prevent GN and GYP Android bots from stomping on
each other. Turns out, they don't, even without this... they're writing
most files to completely separate paths:
- GYP puts most data under $EXTERNAL_STORAGE, generally /sdcard
and its binaries (libdm.so, libnanobench.so, libskia.so, skia_launcher)
in /data/local/tmp;
- GN puts everything under /data/local/tmp, and its binaries (dm, nanobench)
don't overlap GYP's.
So clearing /data/local/tmp was essentially just removing GN's data; GYP's
data file caching was never affected and can't conflict with GN's.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2340473002
Review-Url: https://codereview.chromium.org/2340473002
