Some components in the Flutter engine were derived from the forked blink codebase. While the forked components have either been removed or rewritten, the use of the blink namespace has mostly (and inconsistently) remained. This renames the blink namesapce to flutter for consistency. There are no functional changes in this patch.
Remove platform views inside OnDispose might cause issue if it happens before SubmitFrame and the active_composition_order has not been updated.
We will be left at a situation where the active_composition_order still contains the old view, but the view is actually removed from the UIView hierarchy.
We now cache the views need to be removed in OnDispose and actually remove them in SubmitFrame. At the same time, we remove stop detaching the subviews if they were disposed.
As a side effect, this update will also fixflutter/flutter#30220
Follow up the framework change in flutter/flutter#29304.
Inject the accessibility element tree in the semantic node if the node is for platform views.
flutter/flutter#29302
Layout occurs after [CATransaction commit]. layoutSubviews was where we set the contentsScale on the CALayer. This meant that for one frame, we would see content on the overlay view which was did not have the correct content scale.
This change makes it so that we initialize the FlutterOverlayView with the correct contentsScale.
This also updates the overlay_gr_context_ when we first create the overlay_view. This is an artifact of #8175.
This manifests as jank as seen in: flutter/flutter#29573
Optimize the performance of the platform view composition.
When recomposition is required, we previously remove all the platform view related views (intercepting view, platform view) and re-add them for each frame. This is mentioned in flutter/flutter#23793.
This PR enhanced the performance by re-arrange the existing UIViews and only add the newly created Views.
As a result, it would also fixflutter/flutter#29427
The reason we didn't merge just the gpu and platform threads from the get go was a deadlock in Shell:OnPlatformViewCreated and Shell:OnPlatformViewDestroyed.
The deadlock was caused by the platform thread starting a thread-hopping flow that ends ends up with the gpu thread releasing a latch that the platform thread is waiting on just after starting the cross-thread dance.
If the platform and gpu threads are the same, that last task that is posted to the gpu thread will never get executed as the gpu/platform thread is blocked on a latch.
This works around the deadlock by having a special case in the code for the scenario where the gpu and platform threads are the same.
Fixes: flutter/flutter#23974
There can be cases where SubmitFrame gets called
before overlays are a part of the frame, in these
cases, we should not update the GRContext ahead of time.
This commit makes it so we will update it only when
the frame really shows the overlay.
This addresses: https://github.com/flutter/flutter/issues/28920
Fix for flutter/flutter#27700 and flutter/flutter#24207
There are 2 fixes included in this PR.
The intercepting views sometime pass up the touches events to flutter view, even after the forward gesture recognizer pass the event to the flutter view. We only want the event to be passed to the flutter view once. So we let the intercepting view 'consumes' the event in this PR to fix the problem.
When a touch sequence has multiple touch points participated(e.g. Pinch gesture), the touchesBegan and touchesEnded can be triggered multiple times if the touches do not happen simultaneously. One example would be: when performing a pinch gesture with 2 fingers, I put down one finger, keep the finger on the screen, then put down another finger, perform pinch, lift up both finger at the same time. In this sequence, touchesBegan is called twice with each touch in one of the calls and touchesEnded is called once and has 2 touches in the callback. To handle this issue, we added a count to count the touches in one touch sequence. We only set the state to fail when the count reaches 0(That is all the touches has began in the current sequence is ended).
Link dart:* sources into engine for debugger source support
Currently, dart:* libraries appear to have no source in
debuggers like Observatory. With this change, these sources will be
available in debug mode applications. Sources for dart:* libraries are
lazily loaded on a script-by-script basis.
Refer to https://dart-review.googlesource.com/c/sdk/+/93375 for the Dart
SDK change.
ForwardingGestureRecognizer was previously accepting the gesture when the touch sequence ended, this was causing some other gesture recognizers to not accept the gestures (e.g tapping on the my location button in a Google Map didn't work).
When the app is sent to the background and then brought to the forward it is possible that the GrContext was changed.
This resulted in overlay surfaces not being updated after being backgrounded and foregrounded.
This change makes sure to re-create the overlay rendering surfaces if the GrContext for the main surface was changed.
fixesflutter/flutter#24900
This re-lands commit cc9c670, with a few fixes:
- Keep the DelayingGestureRecognizer a discrete gesture recognizer, when it was set to a began state embedded WkWebViews wasn't receiving touch events.
- Fix a bug of not retaining the forwardRecognizer pointer when assigning it to a scoped_nsobject.
Previously the framework could only tell the engine to forward a touch
sequence to an embeded UIView between the time touches has started and
the time touches ended. This couldn't support gesture arena setups where
the gesture is recognized after the touch sequence is complete (e.g a
tap competing with a scroll).
This change makes it so that a touch gesture is only finally rejected by
a platform view when the framework invokes the `rejectGesture` method.
This allows the framework to resolve a gesture conflict after the touch
sequence was ended.
Consistently handle Int32/Int64 types on both 32-bit and 64-bit versions
of iOS. Drop usage of the obsolete hex string encoding for BigInt types.
Fixes https://github.com/flutter/flutter/issues/21313
Technically both of these are part of the public API exposed in
Flutter.framework. Neither is used within Flutter itself, and both have
been broken since the removal of Dart 1 support, so eliminating rather
than marking unavailable.
