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.
Added `FlutterPluginRegistrantCallback` typedef and optional `setPluginRegistrantCallback` static method in `FlutterPlugin`. `setPluginRegistrantCallback` is used to set a callback defined in AppDelegate.m which registers some subset of plugins with a `FlutterPluginRegistry` (for example, a headless FlutterEngine). This allows for plugins which utilize background execution functionality to enable the use of other plugins on the background isolate. This puts iOS on par with Android for background execution.
Along with updated examples and Medium posts, this fixes [flutter/flutter#21925](https://github.com/flutter/flutter/issues/21925).
Merges the current flutter-desktop-embedding macOS framework into the
engine. Notable changes:
- All channel/codec related code is eliminated in favor of using the
existing iOS implementations.
- All .m files renamed to .mm for consistency with the iOS code.
- Some minor code changes to fix new warnings in Objective-C++ mode.
- License headers, basic format (e.g., clang-format changes) updated to
use repo style.
- Xcode project is not included; instead adds GN build rules to create
an integrated framework that combines what was the FDE library with
what is present in FlutterEmbedder.framework.
Other changes are left as follow-ups, including:
- Moving shared code out of ios/ into common/.
- Potentially improving sharing between iOS and macOS BUILD.gn.
- Class renaming; the FLE prefix will be eliminated, but that API
surface isn't stable yet, so that can be changed later.
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.
Right now we do it whenever the platform views preview flag is on.
This is less efficient, filed
https://github.com/flutter/flutter/issues/24133 to only do this when
there's a platform view in the tree.
Moved the frame buffer specific logic from IOSGLContext to IOSGLRenderTarget.
use recording canvases for overlays
Support platform view overlays with gl rendering.
This also changes the overlay canvases (for both software and gl
rendering) be recording canvases, and only rasterize them after
finishing the paint traversal.
Handing a UIView refererence directly to the engine makes it challenging
for plugin authors to retain a controller for that UIView (e.g the
controller that talks over the platform channel) for as long as the
embedded view is needed.
We instead make the factory return a FlutterPlatformView which is a
wrapper around the UIView that the engine retains as long as the
platform view instance is needed. This allows plugin authors to keep
their control logic in the FlutterPlatformView and know that the engine
is responsible for retaining the reference.
When we visit a PlatformViewLayer during the paint traversal it replaces
the PaintContext's canvas with a new one that is painted ontop of the
embedded view.
We need to make sure that operations applied by parent layers are also
applied to the new canvas.
To achieve this we collect all the canvases in a SkNWayCanvas and use
this canvas by non leaf nodes. Leaf nodes still paint only to the "current"
canvas.
This PR moves the overlay canvas creation from the paint phase to the
preroll phase, collects them into a SkNWayCanvas and set it in
PaintContext.
To keep this PR focused, I only used the internal_nodes_canvas in the
tranform_layer.
Will followup with a PR that changes all internal layers to use the
internal_nodes_canvas.
When the flag is true, we currently use a single thread configuration,
and disabled the raster cache for opacity layers.
The flag's name is 'io.flutter_embedded_views_preview'.
The overlay surfaces are going to be the same IOSSurface implementation
with the platform views controller set to null (so these are surfaces
that don't support embedding platform views to them).
* Adds a FlutterOverlayView which is a UIView that's showing an
overlay surface.
* Creates an overlay surface for each embedded UIView (done in
FlutterPlatformViewsController).
* Changes CompositeEmbeddedView to return a new canvas.
* Makes the PlatformViewLayer replace the PaintContext's canvas with
the canvas for the overlay view.
* Changed canvas in PaintContext to be a pointer so it can be changed.
TBD in following PRs:
* Copy the current canvas state when replacing a canvas in PaintContext.
* Make FlutterOverlayView work with a GL backend (currently it only
works with software rendering)
Also tracks the order of embedded views from frame to frame, and only
removes and reattaches subviews if there is a structural change to the
UIView hierarchy.
