* 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 2d530daeca, but
rolled back in 0a6e415b60 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 d43d353475, and reverted in
459f722b86 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 8ad42f0dae.
* 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.