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
Reason for revert:
This CL breaks Android CTS tests CanvasStateTests#testClipPathReturnValues, CanvasStateTests#testClipRectReturnValues, and CanvasStateTests#testQuickReject.
Reverting it won't significantly affect Android's performance. See the following test result of testInvalidateTree Jank test. (Derek said that this is the only test closely related to this CL.)
**After reverting**
INSTRUMENTATION_STATUS: gfx-max-slow-draw=0.0
INSTRUMENTATION_STATUS: gfx-max-high-input-latency=0.0
INSTRUMENTATION_STATUS: gfx-max-slow-ui-thread=100.0
INSTRUMENTATION_STATUS: gfx-avg-slow-bitmap-uploads=100.0
INSTRUMENTATION_STATUS: gfx-avg-missed-vsync=72.96467105972435
INSTRUMENTATION_STATUS: gfx-avg-high-input-latency=0.0
INSTRUMENTATION_STATUS: gfx-max-slow-bitmap-uploads=100.0
INSTRUMENTATION_STATUS: gfx-max-missed-vsync=73.56181150550796
INSTRUMENTATION_STATUS: gfx-avg-frame-time-90=69.0
INSTRUMENTATION_STATUS: gfx-avg-frame-time-95=69.0
INSTRUMENTATION_STATUS: gfx-avg-frame-time-99=69.0
INSTRUMENTATION_STATUS: gfx-max-jank=100.0
INSTRUMENTATION_STATUS: gfx-avg-slow-draw=0.0
INSTRUMENTATION_STATUS: gfx-avg-slow-ui-thread=100.0
INSTRUMENTATION_STATUS: gfx-max-frame-time-90=69
INSTRUMENTATION_STATUS: gfx-max-frame-time-95=69
INSTRUMENTATION_STATUS: gfx-max-frame-time-99=69
INSTRUMENTATION_STATUS: gfx-avg-jank=100.0
INSTRUMENTATION_STATUS_CODE: -1
.
Test results for InstrumentationTestRunner=.
Time: 77.404
**Before Reverting**
gfx-max-slow-draw=1.1135857461024499
INSTRUMENTATION_STATUS: gfx-max-high-input-latency=0.0
INSTRUMENTATION_STATUS: gfx-max-slow-ui-thread=100.0
INSTRUMENTATION_STATUS: gfx-avg-slow-bitmap-uploads=100.0
INSTRUMENTATION_STATUS: gfx-avg-missed-vsync=70.79687591131983
INSTRUMENTATION_STATUS: gfx-avg-high-input-latency=0.0
INSTRUMENTATION_STATUS: gfx-max-slow-bitmap-uploads=100.0
INSTRUMENTATION_STATUS: gfx-max-missed-vsync=76.94174757281553
INSTRUMENTATION_STATUS: gfx-avg-frame-time-90=67.66666666666667
INSTRUMENTATION_STATUS: gfx-avg-frame-time-95=67.66666666666667
INSTRUMENTATION_STATUS: gfx-avg-frame-time-99=69.0
INSTRUMENTATION_STATUS: gfx-max-jank=100.0
INSTRUMENTATION_STATUS: gfx-avg-slow-draw=0.5317509395832639
INSTRUMENTATION_STATUS: gfx-avg-slow-ui-thread=100.0
INSTRUMENTATION_STATUS: gfx-max-frame-time-90=69
INSTRUMENTATION_STATUS: gfx-max-frame-time-95=69
INSTRUMENTATION_STATUS: gfx-max-frame-time-99=69
INSTRUMENTATION_STATUS: gfx-avg-jank=100.0
INSTRUMENTATION_STATUS_CODE: -1
.
Test results for InstrumentationTestRunner=.
Time: 77.411
OK (1 test)
Original issue's description:
> SkLiteRecorder: don't tell SkCanvas about clips
>
> If no one reads our clip, and we don't expect quickReject() to help,
> we can probably get away without maintaining a proper clip stack.
>
> This puts us at about 0.6-0.7x of previous record cost.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2227833004
>
> Committed: https://skia.googlesource.com/skia/+/8369e32a05543c2619b1d7e740fe6ff6d2f03af3TBR=reed@google.com,mtklein@google.com,mtklein@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=skia:
Review-Url: https://codereview.chromium.org/2335773002
Just to take inventory of which old problems still linger and which are now moot, I've gone out of my way to have this stand alone. All of gn_android_flavor's logic is self contained, without any dependency on the platform_tools scripts.
The tricky bits turn out to be, copying directories containing symlinks---or really any copying involving more than one file---and getting the exit code back from adb shell. Luckily the ADB I've got on my desktop and my Nexus 5x seems to handle this all without the awkward workarounds you see here, so there's hope that One Day Soon the weird parts (basically, anything with inline python) can go away. Once we've got these bots landed green, I'll go see whether the fixes are due to ADB updates, Android updates, or perhaps something else like hardware.
The parts marked TEMPORARY are a nod to the fact that the devices are used by gn_android_flavor and android_flavor both today. It's mostly about not stepping on each other's toes or leaving anything laying around that might confuse each other. The marked parts can go away when bots are either gn_ or non-gn_ but not both.
I have omitted a few steps that may be important, but which are easy independent follow-ups:
- running as root
- locking clocks
- waiting on battery levels
- fancier wait-for-ready than adb wait-for-usb-device
It'd be nice to, e.g., reaffirm that locking clocks helps perf stability, and that we're locking to the best policy. I've tried to keep this CL as trim as possible, leaving any of these vaguely optional steps for later.
As of PS 41 or so, it looks like the trybots are all behaving as expected.
We should expect no new images in Gold. Can we see trybots in Perf yet?
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2320153002
CQ_INCLUDE_TRYBOTS=master.client.skia.android:Perf-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android-Trybot,Perf-Android-Clang-AndroidOne-CPU-MT6582-arm-Release-GN_Android-Trybot,Perf-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-GN_Android-Trybot,Perf-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Release-GN_Android-Trybot,Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android-Trybot,Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Release-GN_Android-Trybot,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-GN_Android-Trybot,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Release-GN_Android-Trybot
Review-Url: https://codereview.chromium.org/2320153002
