We currently use a mix of C standard includes (e.g. limits.h) and their
C++ variants (e.g. climits). This migrates to a consistent style for all
cases where the C++ variants are acceptable, but leaves the C
equivalents in place where they are required, such as in the embedder
API and other headers that may be used from C.
Additionally create "_next" permutations for all of the test binaries
on Fuchsia, in order to test both code-paths.
Using the #define follow-up CLs can also create a flutter_runner_next
binary that does not contain any legacy integration code.
BUG: 53847
This reverts commit 6ea69a0d4339dd153899bb6c299689f1dd43329d.
On top of the revert, it reverted a commit in the PR:
https://github.com/flutter/engine/pull/14024
This reverts commit ea67e5b0b930ebf552bc7dbd678a35ee6a129c39.
Some components in the Flutter engine were derived from the forked blink codebase. While the forked components have either been removed or rewritten, the use of the blink namespace has mostly (and inconsistently) remained. This renames the blink namesapce to flutter for consistency. There are no functional changes in this patch.
Most changes are trivial except pushTransform. In pushTransform, matrix4 is an Dart object and it has to be released before we can return a new Dart object (EngineLayer).
This reverts commit 74662ab695238af0e7402f41c4bf9ad862bd37d2.
This should land after https://github.com/flutter/engine/pull/6442
* Add pragma vm:entry-point
Otherwise, an object may be both null and an instance of EnginieLayer at
the same time in Dart.
To make the PR minimal, we currently only share the engine layer when `pushPhysicalShape` (for Fuchsia) or `pushOffset` (for `RepaintBoundary` and `Opacity`) are called. They should be sufficient for our short-term perf goal. In the future, we can incrementally share more engine layers with the framework.
https://github.com/flutter/flutter/issues/21756
Skia should already have such optimizations based on a much more
accurate clip stack. As we move to the retained rendering, SceneBuilder
would be much harder to maintain such cull_rects_ stack so let's just
remove them.
No significant performance change is measured locally on Moto G4 with
flutter_gallery transition perf test and complex_layout scroll perf
test.
This essentially reverts https://github.com/flutter/engine/pull/4197/
as no one is (or soon will be) implementing an alternative LayerBuilder.
Let's just put everything in SceneBuilder to reduce the YAGNI
(you aren't gonna need it) smell. This will also make retained rendering
API changes much easier.
* Adjust PhysicalModelLayer to use an abstract shape, and provide concrete RRect and Path shape implementations
* add a pushPhysicalShape to scene_builder and compositing.dart
Compute the necessary texture resolution using more accurate scaling
information provided by Mozart scene node metrics events instead of the
device pixel ratio provided by the Mozart view properties (which we
might remove in the future).
This allows us to allocate smaller textures when a Flutter view is
being scaled down.
