This corrects the button state emitted on synthetic pointer move and
hover events generated by the engine.
When an embedder notifies the engine of a pointer up or down event, and
the pointer's position has changed since the last move or hover event,
`PointerDataPacketConverter` generates a synthetic move or hover to
notify the framework of the change in position. In these cases, the
current event from the embedder contains the new button state *after*
the pointer up/down event, but the move/hover needs to be synthesized
such that it occurs *before* the pointer up/down, with the previous
button state.
This patch stores the button state after each pointer down, up, move, or
hover event such that it can be used by the next event if a synthetic
event must be issued.
The bug in the previous logic was revealed by the release of macOS 11
(Big Sur), which appears to issue move events between mouse down and
mouse up, which did not use to be the case.
This fixes https://github.com/flutter/flutter/issues/64961, which is the
desktop-specific tracking bug for the more general Big Sur mouse click
umbrella issue https://github.com/flutter/flutter/issues/71190.
* Revert "Revert "Set SkPath::setIsVolatile based on whether the path survives at least two frames (#22620)" (#23044)"
This reverts commit 4f914253bd7cd2a5cca3fd97213df37494e9bf37.
* Fix tracing
Reland #22505, now that flutter/flutter#70637 has landed.
Removes references to dart:ui.Window, and switch usages to PlatformDispatcher or SingletonFlutterWindow, as appropriate.
This reverts commit d37b862, relanding #22267, now that flutter/flutter#70252 has landed to prevent the problems it had the first time.
Here is the original PR description:
For some reason (probably a bad merge on my part), the return values for locale and locales are not the same on web as they are on other platforms for the PlatformDispatcher and SingletonFlutterWindow classes. The web versions are non-nullable and the others are nullable.
This converts them to be the same (non-nullable) values
For some reason (probably a bad merge on my part), the return values for locale and locales are not the same on web as they are on other platforms for the PlatformDispatcher and SingletonFlutterWindow classes. The web versions are non-nullable and the others are nullable.
This converts them to be the same (non-nullable) values.
Fixes a precision bug was introduced in 784e6d7, 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.
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.
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.
* Revert "Fix documentation build for window changes. (#21780)"
This reverts commit 931a04683d6eb49fc92059b2384ac5b1618d5422.
* Revert "Migration to PlatformDispatcher and multi-window (#20496)"
This reverts commit 85b0031f73544e448354047dc6a236c0b0808252.
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.
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.
