Cleans up header order/grouping for consistency: associated header, C/C++ system/standard library headers, library headers, platform-specific #includes.
Adds <cstring> where strlen, memcpy are being used: there are a bunch of places we use them transitively.
Applies linter-required cleanups. Disables linter on one file due to included RapidJson header. See https://github.com/flutter/flutter/issues/65676
This patch does not cover flutter/shell/platform/darwin. There's a separate, slightly more intensive cleanup for those in progress.
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.
This adds a check for the presence of dart2js in the engine build.
Felt relies on an engine build with `--full-dart-sdk` set. Previously,
we checked for the presence of pub, but not for the presence of
web-specific tooling such as dart2js that felt relies on. Pub is built
as part of the default Dart SDK build when `--full-dart-sdk` is not set,
so its presence is insufficient to prove that other required tooling is
present.
Without this check, we get the following error on run:
Unhandled exception:
ProcessException: No such file or directory
Command: /Users/cbracken/src/flutter/engine/src/out/host_debug_unopt/dart-sdk/bin/dart2js --no-minify --disable-inlining --enable-asserts --enable-experiment=non-nullable --no-sound-null-safety -O2 -o test/paragraph_builder_test.dart.browser_test.dart.js test/paragraph_builder_test.dart
This updates the web_ui implementation of lerpDouble to match the
behaviour of the C++ engine implementation in dart:ui.
Specifically this covers the following changes:
* #20871: stricter handling of NaN and infinity
* #20879: Improve the precision of lerpDouble
lerpDouble: stricter handling of NaN and infinity (#20871)
----------------------------------------------------------
Previously, the behaviour of lerpDouble with respect to NaN and infinity
was relatively complex and difficult to reason about. This patch
simplifies the behaviour with respect to those conditions and adds
documentation and tests.
In general, if `a == b` or both values are null, infinite, or NaN, `a`
is returned. Otherwise we require `a` and `b` and `t` to be finite or
null and the result of the linear interpolation is returned.
Improve the precision of lerpDouble (#20879)
--------------------------------------------
Reduces errors caused by the loss of floating point precision when the
two extrema of the lerp differ significantly in magnitude. Previously,
we used the calculation:
a + (b - a) * t
When the difference in magnitude between `a` and `b` exceeds the
precision representable by double-precision floating point math, `b - a`
results in the larger-magnitude value of `a` or `b`. The error between
the value produced and the correct value is then scaled by t.
A simple example of the impact can be seen when `a` is significantly
larger in magnitude than `b`. In that case, `b - a` results in `a` and
when `t` is 1.0, the resulting value is `a - (a) * 1.0 == 0`.
The patch transforms the computation to the mathematically-equivalent
expression:
a * (1.0 - t) + b * t
By scaling each value independently, the behaviour is more accurate.
From the point of view of performance, this adds an extra
multiplication, but multiplication is relatively cheap and the behaviour
is significantly better.
This patch also adds a `precisionErrorTolerance` constant to
test_utils.dart and migrates existing tests to use `closeTo()` for
testing.
The tests themselves *do* currently use values that have an exact
floating-point representation, but we should allow for flexibility in
future implementation changes.
* `Image.toByteData()` was not implemented in either DomCanvas or CanvasKit. This PR covers **both.**
* `Picture.toImage()` was not implemented in either DomCanvas or CanvasKit. This PR covers **CanvasKit**
Reduces errors caused by the loss of floating point precision when the
two extrema of the lerp differ significantly in magnitude. Previously,
we used the calculation:
a + (b - a) * t
When the difference in magnitude between `a` and `b` exceeds the
precision representable by double-precision floating point math, `b - a`
results in the larger-magnitude value of `a` or `b`. The error between
the value produced and the correct value is then scaled by t.
A simple example of the impact can be seen when `a` is significantly
larger in magnitude than `b`. In that case, `b - a` results in `a` and
when `t` is 1.0, the resulting value is `a - (a) * 1.0 == 0`.
The patch transforms the computation to the mathematically-equivalent
expression:
a * (1.0 - t) + b * t
By scaling each value independently, the behaviour is more accurate.
From the point of view of performance, this adds an extra
multiplication, but multiplication is relatively cheap and the behaviour
is significantly better.
This patch also adds a `precisionErrorTolerance` constant to
test_utils.dart and migrates existing tests to use `closeTo()` for
testing.
The tests themselves *do* currently use values that have an exact
floating-point representation, but we should allow for flexibility in
future implementation changes.
Previously, the behaviour of lerpDouble with respect to NaN and infinity
was relatively complex and difficult to reason about. This patch
simplifies the behaviour with respect to those conditions and adds
documentation and tests.
In general, if `a == b` or both values are null, infinite, or NaN, `a`
is returned. Otherwise we require `a` and `b` and `t` to be finite or
null and the result of the linear interpolation is returned.
The behaviour of lerpDouble with respect to null inputs isn't entirely
obvious. In the case where both inputs are null, it returns null.
Otherwise, it defaults the null parameter to 0.0 and carries on.
Post non-null by default, it might be nice to strengthen the parameter
contract to require them to be non-null. While this would be a breaking
change, it seems likely that the framework either meets this guarantee
or can provide it without a framework breaking change.
https://github.com/flutter/flutter/issues/64617 tracks the above.
In the meantime, adding a test to lock in the current behaviour.
* update chrome version, should be merged after recipe changes
* changing directory to use chrome driver in LUCI
* changing directory path's order
* add cipd packages's chrome version for mac
* addressing reviewer comments
* more documentation. update readme
* remove late since it didn't build. remove distinction in paths for local and LUCI.
* addressing reviewer comments. (non-null fields needs rechanging)
* addressing reviewer comments. adding 2.6 on files missing the notation
* change from build_runner to dart2js
* add internalBootstrapBrowserTest to some of the tests
* add internalBootstrapBrowserTest to all remaining tests
* make tests build in paralel. Total time dropped from 586 to 177 seconds for 8 core MacBook
* change isolates with pool
* fixing analysis errors
* skipping canvaskit tests for ios-safari
* copy image files to the build directory
* adding internalBootstrapBrowserTest to newly added tests
* add internalBootstrapBrowserTest to faling path iterator test
* necessary changes to make chrome windows work
* in windows test in chrome instead of edge. our edge code was for legacy edge
* do not run golden unit tests on Windows LUCI bots for now
* addressing reviewer comments. Adding a method for deciding when to run integration tests.
* remove lines that I forgot to remove
* fixing analysis error. add issue for todo
* add bootstap to a test file
* adding bootstrap to another test
* add internalBootstrapBrowserTest to a golden test
* return test result in bat file. use archieve package to unzip
* fixing logs for chrome_installer
* use archieve and archieve entity instead of dynamic
* adding comments for windows platform archieve part
* addressing reviewer comments
* change readme file
Reland #19396 with a fix for improper scale that was affecting internal tests
Tested: Ran all unittests, ran internal tests, and ran workstation on Fuchsia
BUG: 53062, 53063
