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.
