For measuring the Dart thread, we care about thread duration (tdur) rather than
wall duration (dur) because we don't want to count the time when the Dart
thread is descheduled (e.g., in preference to the raster thread).
Prior to this change, these benchmarks were mostly measuring whether the OS
decided to finish the Dart thread's time slice or hand over the CPU to the
raster thread to complete the visual part of the frame. Now we actually measure
the work done on the Dart thread.
When a ListView scrolls, it generates a LayoutChangedNotification, which was
causing Material to repaint unconditionally. That's not necessary if there are
no ink effects that need to be moved. This patch skips the repaint in that
case.
Fixes#7937
This test was a bit tricky to convert because it subtly relied upon the
lazy evaluation of an Iterable.
The onDismissed from Dismissable happens during the animation phase of
the pipeline. Previously, the ScrollableList had already been built for
that frame but had not evaluated its Iterable yet. When we got to the
layout phase, ScrollableList evaluated its Iterable and saw the updated
version of dismissedItems.
A straightforward conversion to ListView calls toList() when building
the ListView, but that evaluates the iterable when buildTest() is
called, which is before the calls to pump and therefore before the
animation phase, meaning the Iterable sees the old value of
dismissedItems.
This patch fixes the test to use the normal setState pattern to signal
that state upon which the build depends has changed. Now, the
onDismissed callback happens during the animation phase and the
StatefulBuilder is marked as dirty via setState, which causes it to
rebuild the ListView and re-evaluate the Iterable, seeing the updated
version of dismissedItems.
This change also lets us replace the gratuious use of pumpWidget with
pump now that we use setState rather than pumpWidget to trigger a
rebuild.
* Make new project template gradle-based for Android.
With this change, the 'new project' template uses the same gradle-based build for Android as the hello_services example. This has some implications on build performance, since we're now building a complete Android app instead of just combining a pre-compiled .dex with the Flutter assets.
The very first build is a little over 2x slower, since it needs to download gradle and build the build scripts before getting to the actual code. Subsequent builds with changes to the code are comparable to the old builds. Null builds are faster. Enabling the gradle daemon speeds up subsequent builds by around 5s.
* Move Flutter Gradle plugin to Flutter root.
Required to handle Flutter SDK (and other) paths that include spaces.
Also includes general cleanup:
* Declare explicitly that we use /bin/bash, since we rely on its
features.
* Add -- where possible, to avoid interpreting files starting in - as
options.
* Suppress output of pushd/popd.
* Avoid stringifying arrays.
