* Enable flutter engine to also work with .*so files on android
We would like to be able to use native tools (e.g. simpleperf, gdb) with
precompiled flutter apps. The native tools work much better with *.so
files instead of the custom formats the Dart VM uses by default.
This CL adds support for being able to load the flutter app from an *.so
file on Android.
* Add sanity check to ensure we have either shared library or instruction snapshot (but not both)
When checking whether render buffer size has changed, apply the device
scale factor used to convert points to pixels to ensure we're not
needlessly re-allocating render buffer storage.
Adds trace + debug log to make this easier to detect in future.
Originally introduced in 2d530daeca438ca24562d290616c0aec5ab76b88, but
rolled back in 0a6e415b60581ef7934032df20401da1fae9ea9f to test whether
it was responsible for regressions to
flutter_gallery_ios__transition_perf benchmarks:
* average_frame_build_time_millis
* missed_frame_build_budget_count
Re-landed in d43d35347594c893687dec7402a525d83f57db10, and reverted in
459f722b86415da01386fe41f37bafa842f11ae8 after it appeared to regress
the above two benchmarks. After recent changes to microtask execution
order which fixed https://github.com/flutter/flutter/issues/9998,
re-introducing this fix results in benchmark improvements to the above
two benchmarks in local testing.
Fixesflutter/flutter#13018
When linear blending was disabled, we started rendering directly to FBO0 again. We can't attach stencil there, and the profile graph code triggers a path that (by default) uses it. This option forces us to use alternate rendering methods.
Note that the graph rendering code is constructing a fairly complex path. It would probably be much faster to render as a simpler series of drawRect calls for each box (which would get batched inside Skia).
This retains gamut correction (adjusting colors for screens with different capabilities), but does all blending and interpolation with sRGB-encoded values. That matches the behavior expected by most users, as well as the behavior of nearly all other systems. It also greatly simplifies the EGL code.
A future Skia change will make this behavior more of a first-class citizen, so some of these implementation details will change again, but the behavior will not. The bulk of this change (elimination of complication from the GL surface code) is permanent - it's just the SkColorSpaceXformCanvas that will be replaced.
With the update to HEAD of the Fuchsia buildtools repo, the new clang
toolchain picked up caused link-time breakage in android x86_64
libFlutter.so builds.
Sample log:
https://build.chromium.org/p/client.flutter/builders/Linux%20Engine/builds/1974/steps/build%20android_debug_x64/logs/stdio
Sample failure:
FAILED: libflutter.so libflutter.so.TOC lib.stripped/libflutter.so
../../third_party/android_tools/ndk/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: obj/flutter/shell/platform/android/libflutter/android_context_gl.o: unsupported reloc 42 against global symbol std::__ndk1::num_put<char, std::__ndk1::ostreambuf_iterator<char, std::__ndk1::char_traits<char> > >::id
This reverts commit 8ad42f0dae3cb1267c2b9ab99db80e4696ddbc3d.
* Roll Fuchsia buildtools to 85907c59e97527d79bbfdfd849d8e85c24959cc5
This also updates Flutter buildroot to a6e52dbb776c45cc8c57d7143b8eb8b2e762fdfb
which disables -Wtautological-constant-compare temporarily until
https://reviews.llvm.org/D39462 lands in clang. This is in line with
Fuchsia's compiler options.
* Apply clang-format diffs
No logical changes. This applies clang-format from the latest Fuchsia
buildtools to the engine codebase.
There are two different sets of view insets that applications may want
to track in order to avoid unwanted interaction with system UI:
1. OS UI that effectively shrinks the Flutter view from a UX point of
view: e.g., when the keyboard opens, it occludes the bottom of the
screen and the view should be adjusted such that the bottom, for the
purposes of scrolling is just above the keyboard.
2. OS UI that is overlaid over the application, but into which the
application should draw. e.g., the Home indicator on the iPhone X
typically appears near the bottom of the screen, overlaid over app
content. Content should be rendered within this 'safe area' but apps
should avoid requiring user interaction there. For example, list
views may want to include some small amount of additional padding to
ensure the last list item can scroll above this area.
Since Flutter does not currently distinguish between these two cases,
this patch disables the bottom safe area inset until API is added to
support these separately.
This change exposes the view safe area insets (introduced in iOS 11) to
the framework via MediaQuery.of(context).padding. Safe area insets are
the view insets (padding) inside of which content can be relied on to
display without truncation/clipping, as would occur with e.g. the iPhone
X sensor notch.
As this API was added in iOS 11, we place it behind a runtime guard
checking OS level.
Until the runtime support for @avialable lands in the next Fuchsia
buildtools rev, ignore -Wunguarded-availability-new around the safe area
insets check and use an FML runtime check instead.
* Read core platform kernel file during Dart initialization.
Currently service isolate is initialized from the source code parsed by VM.
This CL changes it so service isolate created during Dart initialization
is created from the kernel platform.dill file if it is present in the application
bundle. Then this platform kernel file is kept in dart_init module and reused
for application sciprt isolates.
* Reformat and merge
* Use accessor method
* Avoid passing running_from_kernel param. Add TODO for cleanup. Rename param.
