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
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.
* WIP on Paragraph
* WIP skparagraph
* Add more Paragraph features in CanvasKit mode
* Fix addRoundRect test
* Respond to review comments
* Remove unused (and potentially harmful) getters from Sk classes
* enabling firefox screenshot tests. adding to documentation
* test with correct goldens
* update goldens SHA
* change the goldens with flutter/goldens repo
* do not run preparation step twice. this will cause test_results to be deleted
* Revert "Fix documentation build for window changes. (#21780)"
This reverts commit 931a04683d6eb49fc92059b2384ac5b1618d5422.
* Revert "Migration to PlatformDispatcher and multi-window (#20496)"
This reverts commit 85b0031f73544e448354047dc6a236c0b0808252.
* carrying code
* more changes for carrying the code
* rebase changes onto ios-screenshot tests
* adding screenshot capability to text_editing e2e test
* address some comments
* change enable flag for isUnitTestsScreenshotsAvailable
* addressing the reviewer comments
* change the dependency for path
* add to licencense file
* changing goldens commit no. the new commit has the screenshot goldens
* update readme file
* firefox tests needs LUCI changes
* change to release mode since screenshots were taken in release mode
* change window size
* some argument changes
* small comment change
* test the chrome linux tests again
* use roboto font instead of default font
* addressing reviewer comments
* change commit for goldens
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.
* Move shader.dart into shaders directory
* Add Shader builder basic structure and decls
* rewrite drawVertices with ShaderBuilder
* Fix in parameters in fragment shader to use varying for webgl1
Adds a reference to RenderObject.describeSemanticsClip to
`SemanticsFlag.isHidden` and a hint that lets readers know that the
`SemanticsNode` rect is specified in local coordinates.
* Remove unnecessary `?`s from web_ui.
In https://dart-review.googlesource.com/c/sdk/+/163841, dart's flow
analysis is being changed so that an assignment like this:
T? x = <non-nullable value>;
causes `x` to be immediately promoted to type `T`. This exposed two
instances in which a variable was unnecessarily given a nullable type.
To avoid warnings, we need to fix these two types before
https://dart-review.googlesource.com/c/sdk/+/163841 can land.
* enable ios safari screenshot tests
* this is the value used for screenshots in the repo.
* change revision
* fix the error made in the gaps
* do not try to fetch on LUCI
* lunix luci migth break existing prs. only skip fetching for mac
* add a placeholder tests for shadow golden test
* try to use iPhone 11 Pro on LUCI
* change the scale and the smoke test image
* add unmerged goldens PR to tests all the screenshots. will be removed later
* change the goldens lock back to flutter/goldens
* change wrong comment on screenshot tests block
* address reviewer comments
* change the commit number for goldens file
* skip canvas blend mode tests
* debugging LUCI error
* debugging LUCI error printing directory contents
* skip one test, remove the debug logs
* change the revision number to include the correct chrome files
Allows for reference counting of images before disposal.
This will allow multiple callers to hold a reference to an image and dispose of their reference without disposing the underlying image until all handles have been disposed.
This will be used by the framework to help resolve some of the kludge I was trying to introduce in flutter/flutter#64582
Registering the service worker immediately after the documented has loaded may cause SW initialization to compete with framework initialization. It was recommended to us that we defer the service worker setup until after the framework is done with setup, which should be sometime after the first frame.
To implement this, the binding will dispatch a platform message on startup. This can be listened for in the html document
#66066
