- 18 11月, 2020 1 次提交
-
-
由 Ian Hickson 提交于
-
- 17 11月, 2020 1 次提交
-
-
由 Jenn Magder 提交于
-
- 13 11月, 2020 1 次提交
-
-
由 LongCatIsLooong 提交于
-
- 07 11月, 2020 1 次提交
-
-
由 Zachary Anderson 提交于
This appears to be blocking the Dart SDK roll.
-
- 06 11月, 2020 2 次提交
-
-
由 Jonah Williams 提交于
-
由 Ian Hickson 提交于
-
- 05 11月, 2020 1 次提交
-
-
由 freiling 提交于
-
- 03 11月, 2020 2 次提交
-
-
由 Daco Harkes 提交于
and roll Dart to 52783837369de45d3372cb6c6b7cdd63e71cd829.
-
由 Chris Yang 提交于
-
- 31 10月, 2020 2 次提交
-
-
由 xster 提交于
-
由 Chris Yang 提交于
-
- 30 10月, 2020 3 次提交
-
-
由 Siva 提交于
-
由 stuartmorgan 提交于
-
由 Kaushik Iska 提交于
-
- 29 10月, 2020 1 次提交
-
-
由 Yuqian Li 提交于
-
- 27 10月, 2020 1 次提交
-
-
由 godofredoc 提交于
* Add metrics scripts in preparation to move the builder to LUCI. Bug: https://github.com/flutter/flutter/issues/67579 * set -ex to fail scripts inmediately.
-
- 25 10月, 2020 1 次提交
-
-
由 Chris Bracken 提交于
Fixes a precision bug was introduced in 784e6d74, which improved the precision of lerpDouble when the extrema differed significantly in magnitude. _lerpInt doesn't have this issue since the extrema are passed as 64-bit twos-complement values, therefore the difference will always be accurate so long as it doesn't overflow. This reverts the _lerpInt implementation to the original a + (b - a) * t, but adds a test to avoid a regression if anyone is tempted to make it consistent with the others.
-
- 24 10月, 2020 3 次提交
-
-
由 Filip Filmar 提交于
-
由 Dan Field 提交于
- 23 10月, 2020 2 次提交
-
-
由 xster 提交于
-
由 Greg Spencer 提交于
This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail. Below is the description from the original PR: This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window. The design doc for this change is here. The major changes in this PR: Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class. Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton). Next step after this PR lands: Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first. The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
-
- 20 10月, 2020 1 次提交
-
-
由 Clement Skau 提交于
-
- 17 10月, 2020 4 次提交
-
-
由 godofredoc 提交于
* Collect logs in the background. * Use fuchsia_ctl log_file option. * Delete the correct file. * Remove commented code.
-
由 Chris Bracken 提交于
Eliminates FLUTTER_NOLINT where they can be landed without triggering lint failures.
-
由 Chinmay Garde 提交于
Snapshots compiled with sound null-safety enabled require changes to the way in which isolates are launched. Specifically, the `Dart_IsolateFlags::null_safety` field needs to be known upfront. The value of this field can only be determined once the kernel snapshot is available. This poses a problem in the engine because the engine used to launch the isolate at shell initialization and only need the kernel mappings later at isolate launch (when transitioning the root isolate to the `DartIsolate::Phase::Running` phase). This patch delays launch of the isolate on the UI task runner till a kernel mapping is available. The side effects of this delay (callers no longer having access to the non-running isolate handle) have been addressed in this patch. The DartIsolate API has also been amended to hide the method that could return a non-running isolate to the caller. Instead, it has been replaced with a method that requires a valid isolate configuration that returns a running root isolate. The isolate will be launched by asking the isolate configuration for its null-safety characteristics. A side effect of enabling null-safety is that Dart APIs that work with legacy types will now terminate the process if used with an isolate that has sound null-safety enabled. These APIs may no longer be used in the engine. This primarily affects the Dart Convertors in Tonic that convert certain C++ objects into the Dart counterparts. All known Dart Converters have been updated to convert C++ objects to non-nullable Dart types inferred using type traits of the corresponding C++ object. The few spots in the engine that used the old Dart APIs directly have been manually updated. To ensure that no usage of the legacy APIs remain in the engine (as these would cause runtime process terminations), the legacy APIs were prefixed with the `DART_LEGACY_API` macro and the macro defined to `[[deprecated]]` in all engine translation units. While the engine now primarily works with non-nullable Dart types, callers can still use `Dart_TypeToNonNullableType` to acquire nullable types for use directly or with Tonic. One use case that is not addressed with the Tonic Dart Convertors is the creation of non-nullable lists of nullable types. This hasn’t come up so far in the engine. A minor related change is reworking tonic to define a single library target. This allows the various tonic subsystems to depend on one another. Primarily, this is used to make the Dart convertors use the logging utilities. This now allows errors to be more descriptive as the presence of error handles is caught (and logged) earlier. Fixes https://github.com/flutter/flutter/issues/59879
-
由 Chris Bracken 提交于
This removes most of the remaining FLUTTER_NOLINT comments and opts these files back into linter enforcement. I've filed https://github.com/flutter/flutter/issues/68273 to require that all FLUTTER_NOLINT comments be followed by a GitHub issue URL describing the problem to be fixed.
-
- 14 10月, 2020 1 次提交
-
-
由 Dan Field 提交于
- Build OCMock as a dylib for iOS tests - Set install_name for ios_flutter_test and ocmock dylibs - Copy and sign dylibs during build process
-
- 13 10月, 2020 2 次提交
-
-
由 Zachary Anderson 提交于
This is to unblock a Dart -> engine roll.
- 12 10月, 2020 1 次提交
-
-
由 LongCatIsLooong 提交于
-
- 10 10月, 2020 1 次提交
-
-
由 Greg Spencer 提交于
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window. The design doc for this change is here. The major changes in this PR: Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class. Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton). Next step after this PR lands: Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first. The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
-
- 09 10月, 2020 1 次提交
-
-
由 Kaushik Iska 提交于
-
- 08 10月, 2020 2 次提交
-
-
由 Pieter van Loon 提交于
-
由 Kaushik Iska 提交于
-
- 01 10月, 2020 1 次提交
-
-
由 fredlee12345678 提交于
-
- 30 9月, 2020 1 次提交
-
-
由 bungeman 提交于
Skia is removing the deprecated legacy display setting globals and associated kLegacyFontHost_InitType. This change replaces all such uses with default surface properties with no special flags and an unknown pixel geometry. Flutter never set the associated globals, leaving them with their initial default values, which were no special flags and horizontal RGB pixel geometry. The values used here are different but this change should make no difference as Flutter never mentions SkFont::kSubpixelAntiAlias to take advantage of the pixel geometry.
-
- 29 9月, 2020 1 次提交
-
-
由 George Wright 提交于
-
- 26 9月, 2020 2 次提交
-
-
由 Dan Field 提交于
-
由 Alexander Brusher 提交于
Revert "Revert "Adds fuchsia node roles to accessibility bridge updates. (#20385)" (#20936)" (#21367) This reverts commit 96efe392.
-