- 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
Currently the SkTypeface_FreeType::onGetAdvancedTypefaceMetrics
synthesized glyph to Unicode mapping returns the Unicode point
of the last character to map to the glyph. In practice it is
better to guess the first character to map to the glyph instead.
BUG=359065
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2329953003
Review-Url: https://codereview.chromium.org/2329953003
Kind of a big change, to connect several new bits into something useful:
* ID tracking & lookup
* new asPaint() node virtual to support shader (and in the future filter) based paint servers
* <defs>, <linearGradient> and <stop> element support
* 'href', 'offset', 'stop-color', 'stop-opacity' attribute support
* IRI/FuncIRI and rgb(...) parsing
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2327233003
Review-Url: https://codereview.chromium.org/2327233003
What do you think of this? It's basically what you wrote, factored differently.
Flipping on skia_use_freetype will enable the SkFontHost_Freetype*.cpp files
via the :typeface_freetype target.
Then we just pull out the SkFontMgr Fuchsia wants to use into its own little
:fontmgr_fuchsia target. No major difference here, except the availability
of freetype headers, etc, is a bit more tightly scoped to just those that
need them.
We (obviously?) don't have Fuchsia builders, so I've got to rely on you for sanity testing this.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2333913002
Review-Url: https://codereview.chromium.org/2333913002
