Adds a flag to create non-resizeable windows.
Since the number of parameters is getting awkward, extracts
window-related parameters and engine-related parameters into structs for
clarity. This also removes some duplication in method signatures.
The window parameters struct change is also made to the C++ wrapper,
making this a breaking change for the runners.
Fixes https://github.com/flutter/flutter/issues/37623
Rather than running the runloop forever, have the API expose an incremental runloop. This allows clients to do other processing if they need it.
This allows for removing the odd construction of having knowledge of GTK event handling built into the library even though nothing in the library uses it; instead runner applications that use GTK plugins (such as FDE's testbed) can do that processing at the application level instead.
Adds initial use of App.framework in the macOS project configuration,
using that rather than the main bundle as the default Dart bundle, and
expecting flutter_resources to be located there.
This is an incremental step toward aligning with the behvaior of the iOS
version of this class.
Fixes https://github.com/flutter/flutter/issues/38363
No functional change. Just makes testing with fixture images easier. Adding a
whole lot more tests that use this path for the embedder surface rotation
patches. Want to land stuff in smaller chunks.
change_install_name.py was operating on framework library files
in-place, which breaks GN's timestamp analysis handling since a file
can't be both an input and output of an action. As a result no-op builds
on macOS were not actually no-ops.
This changes the script to operate on an output copy, both fixing the
no-op build issue, and simplifying the GN framework construction scripts
by combining the copy step and the install-name step.
Fixes https://github.com/flutter/flutter/issues/33465
The root canvas is managed by the external view embedder when using a custom
compositor. Due to this, frame submission on the surface will not end up
flushing the same (because the surface doesn’t have it to begin with). Fixed
with tests.
This test queues tasks to a custom task runner that runs the tasks on the
platform thread. After shutting down the engine, the test must wait until
these tasks are drained before the test exits.
This issue would only manifest when a custom task runner was being used with
a custom compositor. Both were tested separately but not together. A new
test has been added for this. We still create the GPU thread merger
unnecessarily but I can patch that later. I also cleaned up the existing
custom task runner test to not submit tasks on a dead engine as they just
log errors unnecessarily.
Filed new: https://github.com/flutter/flutter/issues/38844
Previously the test wasn't correctly re-building the engine when its
files changed on multiple runs of `testing/run_tests.py`. It looks like
this is because the test build target wasn't depending on the entire
engine Android dependency, so some code changes were being ignored.
Update the build.
The engine's activity_running flag tracks whether the app is in the paused or
running lifecycle state. The engine had been defaulting activity_running to
false (meaning paused). But the animator had been defaulting its paused flag
to false, which allowed frames to render at startup. If the engine loses and
regains its surface, then frames would stop rendering because activity_running
is false (even though frames had been rendering when the engine initially
acquired its surface).
This change puts the engine and the animator into a consistent state at
startup. Frames will continue to render until the embedder sends a lifecycle
message that will pause both the engine and the animator.
See https://github.com/flutter/flutter/issues/32624
Renames all FLE* classes in the macOS embedding to Flutter*. With the exception
of -[FlutterDartProject engineSwitches], which is very clearly called out in the
comment, the APIs should be stable at this point, so the marker prefix is no
longer needed.
This is a breaking change for macOS embedders, but going forward breaking
changes at the source level for the macOS API should now be rare.
Some of these classes will likely merge with the iOS versions in the future (e.g.,
FlutterDartProject), but that will be an implementation detail that will not affect
clients.
Fixesflutter/flutter#31735
Start work on flutter/flutter#30726 by adding an alternative win32 shell platform implementation for Windows that is not based on GLFW and that uses LIBANGLE for rendering and native win32 windowing and input. This change does not replace the GLFW implementation but rather runs side by side with it producing a secondary flutter_windows_win32.dll artifact. The following items must be added to attain parity with the GLFW implementation:
- Custom task scheduling
- Support for keyboard modifier keys
- Async texture uploads
- Correct high DPI handling on Windows versions < 1703
and will be added in subsequent changes.
The dynamic linker on some older versions of Android on x86 fails when doing
dlsym(RTLD_DEFAULT) lookups of symbols exported by the engine library itself.
The engine needs to do this for some data files that are linked into the engine
library (ICU data and Dart snapshot blobs).
To work around this, the engine will declare static symbols for these data
objects on the affected platforms.
Fixes https://github.com/flutter/flutter/issues/20091
This patch allows embedders to split the Flutter layer tree into multiple
chunks. These chunks are meant to be composed one on top of another. This gives
embedders a chance to interleave their own contents between these chunks.
The Flutter embedder API already provides hooks for the specification of
textures for the Flutter engine to compose within its own hierarchy (for camera
feeds, video, etc..). However, not all embedders can render the contents of such
sources into textures the Flutter engine can accept. Moreover, this composition
model may have overheads that are non-trivial for certain use cases. In such
cases, the embedder may choose to specify multiple render target for Flutter to
render into instead of just one.
The use of this API allows embedders to perform composition very similar to the
iOS embedder. This composition model is used on that platform for the embedding
of UIKit view such and web view and map views within the Flutter hierarchy.
However, do note that iOS also has threading configurations that are currently
not available to custom embedders.
The embedder API updates in this patch are ABI stable and existing embedders
will continue to work are normal. For embedders that want to enable this
composition mode, the API is designed to make it easy to opt into the same in an
incremental manner.
Rendering of contents into the “root” rendering surface remains unchanged.
However, now the application can push “platform views” via a scene builder.
These platform views need to handled by a FlutterCompositor specified in a new
field at the end of the FlutterProjectArgs struct.
When a new platform view in introduced within the layer tree, the compositor
will ask the embedder to create a new render target for that platform view.
Render targets can currently be OpenGL framebuffers, OpenGL textures or software
buffers. The type of the render target returned by the embedder must be
compatible with the root render surface. That is, if the root render surface is
an OpenGL framebuffer, the render target for each platform view must either be a
texture or a framebuffer in the same OpenGL context. New render target types as
well as root renderers for newer APIs like Metal & Vulkan can and will be added
in the future. The addition of these APIs will be done in an ABI & API stable
manner.
As Flutter renders frames, it gives the embedder a callback with information
about the position of the various platform views in the effective hierarchy.
The embedder is then meant to put the contents of the render targets that it
setup and had previously given to the engine onto the screen (of course
interleaving the contents of the platform views).
Unit-tests have been added that test not only the structure and properties of
layer hierarchy given to the compositor, but also the contents of the texels
rendered by a test compositor using both the OpenGL and software rendering
backends.
Fixes b/132812775
Fixesflutter/flutter#35410
Prevents NPEs and simplifies the code needed to handle these collections. There doesn't seem to have been a meaningful difference between null and empty collection here. The specific crash was happening when `object.scrollChildren > 0` while `object.childrenInHitTestOrder == null`, which looks like it may be a bug on its own and probably needs further investigation.
After pre-roll we know if there have been any mutations made to the IOS embedded UIViews. If there are any mutations and the thread configuration is such chat the mutations will be committed on an illegal thread (GPU thread), we merge the threads and keep them merged until the lease expires. The lease is currently set to expire after 10 frames of no mutations. If there are any mutations in the interim we extend the lease.
TaskRunnerMerger will ultimately be responsible for enforcing the correct thread configurations.
This configuration will be inactive even after this change since still use the same thread when we create the iOS engine. That is slated to change in the coming PRs.
Previously this script was not reporting any JUNit failures and somehow
ended up included a non-existent jar for Java tests to test against.
It looks like one of the JUnit tests is now failing. Disabling it for
now to turn on CI again as soon as possible, will fix and enable it in a
follow up.
