It turns out that Skia is much slower at drawing paint inside a clipped
path than directly drawing that path. (Average frame time of 22ms vs
18ms in flutter_galary transition test.)
The behavior of acquire+release annotation handling has changed in
https://reviews.llvm.org/D49355 which breaks the build with the new
Clang. However, as has been pointed out, the acquire+release isn't
the right way to prevent double locking as the annotations negate
each other; the correct way is to use excludes or negative requires.
Using excludes annotations also requires using std::lock_guard instead
of std::unique_lock because the latter doesn't have the thread
annotations due to deferred locking which is not needed in Flutter and
so std::lock_guard is a sufficient alternative.
If we want to avoid the bleeding edge artifact (flutter/flutter#18057 (comment)) using saveLayer, we have to call drawPaint instead of drawPath as anti-aliased drawPath will always have such artifacts.
This is discovered when I try to add golden tests for such bleeding artifacts using our new Clip enum. Here's the updated golden files: flutter/goldens@cb1fa8a?short_path=57b30ce#diff-57b30cea9b10b7ca689009854e12d70e
* Flush all embedded Android view on hot restart.
Adds an OnEngineRestarted method to PlatformView, this is currently only
implemented for Android where we need to use it for embedded views.
* review comments followup
* rename to OnPreEngineRestart, call before Clone
Instead, send them with the new unknown PointerDeviceKind.
We hit this when running `adb shell input tap` in tests which sends events with
an unknown tool type.
This also fills in a missing conversion for TOOL_TYPE_ERASER.
* Add an explicit `-[FlutterViewController init]` implementation
`-[FlutterViewController init]` currently works because it inherits
the `-[UIViewController init]` convenience initializer that invokes
the `-[UIViewController initWithNibName:bundle:]` designated
initializer that `FlutterViewController` overrides.
However, this doesn't seem to be explicitly documented, so it's a bit
confusing (or at least non-obvious), and it seems potentially
brittle. Add an explicit implementation of `-[FlutterViewController
init]` instead.
* Deprecate -[FlutterDartProject initFromDefaultSourceForConfiguration] (#18886)
`-[FlutterDartProject initFromDefaultSourceForConfiguration]` no
longer seems very useful. It calls `-initWithPrecompiledDartBundle:`
or `-initWithFlutterAssets:dartMain:packages:`, but since it now
passes `nil` for all arguments, both paths end up doing the same
thing.
Additionally, `-initFromDefaultSourceForConfiguration` is awkward to
use in Swift. The automatically generated Swift interface is:
public convenience init!(fromDefaultSourceForConfiguration: ())
and it's not obvious how to call that.
Let's deprecate `-initFromDefaultSourceForConfiguration` and instead
expect callers to use the existing `-init` method. (We can make
`-init` do different things for different build configurations later
if necessary.)
Bonus: Rename some parameters to make it more obvious when they may
be `nil`.
Don't emit a "VSYNC" event when running on Fuchsia, as traces on Fuchsia
are typically recorded across the whole system, causing the events to
collide with each other.
Using a custom container image, we reduce the test time from 5 minutes to 2 minutes as we no longer run gclient sync from zero.
In the future, we may be able to cache the ninja output in the image (which probably gets updated daily) so we no longer compile from zero.
This reduces the build time from 5 minutes to 3 minutes as we no longer need to cold start a GCE instance. Moreover, we can now compile the host engine using this container.
This fixes issue with compilation trace buffer getting released upon return from VM code to Dart code, before it gets change to save to a file in natives.dart saveCompilationTrace().
