This reverts commit fcc4ab32301396986dd5103d6d444bff35fe0f63.
Fixes https://github.com/flutter/flutter/issues/41394 and other
related correctness issues.
TBR: @arbreng @jason-simmons @mehmetf
Started asserting the FlutterEngine is running before communicating
over channels. This changes a null pointer exception to an
NSException that will provide some meaningful data to clients
incorrectly using the engine in an add-to-app situations.
- Don't use 'unhandled' as that implies fatality which this is not
- Don't mention shutdown because this is not necessarily an exception-after-shutdown issue
Follow-up issue filed https://github.com/flutter/flutter/issues/41506 to implement the unit test for this.
Made creating and using a FlutterEngine a bit easier, to try to get it get it as easy to use as Android's equivalent.
* Added a default entrypoint variable.
* I added `run` to and `initWithName:` to FlutterEngine.
This change modifies the accessibility bridge so that if a node has input focus, then it will tell TalkBack so that it will request the accessibility focus for the view.
It also sets the content change types bit field to include CONTENT_CHANGE_TYPE_SUBTREE to indicate that the subtree for the view has changed for API levels after, and including, KitKat (19)
Samsung's Korean keyboard has a bug where it always attempts to combine
characters based on its internal state, ignoring if and when the cursor
is moved programmatically. EG typing "ㄴㅇ" and then moving the cursor
back to the front of the text and typing "ㄴ" again would result in
"ㄴㅇㄴ", not "ㄴㄴㅇ".
Fully restarting the IMM works around this because it flushes the
keyboard's internal state and stops it from trying to incorrectly
combine characters. However this also has some negative performance
implications, so we only apply the workaround on Samsung devices set
to use Korean input.
This also effectively disables the feature on Samsung keyboards that
allowed users to re-open a composing region for previously typed
characters. See https://github.com/flutter/flutter/issues/29341#issuecomment-531283508.
Fixesflutter/flutter#29341.
On Fuchsia, add a build flag for compositing OpacityLayers using the system
compositor vs Skia, which exposes a fastpath for opacity via Scenic.
This will only work under certain circumstances, in particular nested
OpacityLayers will not render correctly!
On Fuchsia, add a build flag for compositing PhysicalShapeLayers using
the system compositor vs Skia. Set to off by default, which restores
performant shadows on Fuchsia.
Remove the opacity exposed from ChildView, as that was added mistakenly.
Finally, we centralize the logic for switching between the
system-composited and in-process-composited paths inside of
ContainerLayer. We also centralize the logic for computing elevation
there. This allows the removal of many OS_FUCHSIA-specific code-paths.
Test: Ran workstation on Fuchsia; benchmarked before and after
Bug: 23711
Bug: 24163
* Fix broken tests
This changes writes the required and current Android SDK level to the exception message. This enables Crash Reporting tools to capture more information about this crash.
[flutter_runner] use dedicated allocation info
This informs the vulkan driver that we're allocating memory
dedicated to a single image. This is required for aemu and
might also allow future drivers to make optimizations currently
not possible.
No change in behavior. Existing tests (modular_tests,
scenic_tests, etc.) are sufficient and regressions will be
prevented by running these tests on aemu.
DX-939 #comment
Test: fx shell run fuchsia-pkg://fuchsia.com/basemgr#meta/basemgr.cmx --base_shell=fuchsia-pkg://fuchsia.com/spinning_cube#meta/spinning_cube.cmx
Change-Id: If4ecd9aaa09f12f94654a68e8e9fe979748f44af
[flutter_runner] use external image create info
DX-939 #progress
MA-394 #progress
This informs the vulkan driver that we're creating an image
that will be backed by external memory. The driver driver can
decide to use different memory requirements based on the if
memory for the image can be exported or not.
No change in behavior. Existing tests (modular_tests,
scenic_tests, etc.) are sufficient and regressions will be
prevented by running these tests on aemu.
Test: fx shell run fuchsia-pkg://fuchsia.com/basemgr#meta/basemgr.cmx --base_shell=fuchsia-pkg://fuchsia.com/spinning_cube#meta/spinning_cube.cmx
Change-Id: I489318c2e31f752f76c80a81245e203861d44d94
Explicitly set |Application|'s |flutter::Settings| |trace_skia| field to
false (it currently defaults to false), in order to slightly simplify
the enabling skia trace events workflow.
PT-145 #comment-patch
Change-Id: Ib40f9ed3dc6f824056465db2cd45309c78b7e3b4
Build rules still reference creating share snapshot data and instructions. This makes the engine to always pass them as empty to the dart vm. To be followed up with a change to alter the build rules to stop referencing the shared snapshots.
This is not being used currently and the fact that the runner will be built outside of the flutter tree means that the apps will not have much to gain via shared snapshots. The rationale behind this change is to partially make migrating the runner out of topaz tree easier.
Change-Id: Ibc4dd6a298d65082416af753522f5a17c88a750a
The earlier design speculated that embedders could affect the same
transformations on the layers post engine compositor presentation but before
final composition.
However, the linked issue points out that this design is not suitable for use
with hardware overlay planes. When rendering to the same, to affect the
transformation before composition, embedders would have to render to an
off-screen render target and then apply the transformation before presentation.
This patch negates the need for that off-screen render pass.
To be clear, the previous architecture is still fully viable. Embedders still
have full control over layer transformations before composition. This is an
optimization for the hardware overlay planes use-case.
Fixes b/139758641
The tests we write must be resilient to the order in which they are run in the
harness. That is, they must not rely on global state set by other tests that
have already run in the process. Also, these tests must themselves be
repeatable. That is, they must correctly clean up after themselves and be able
to run successfully again in the same process.
This patch adds some safeguards against (but does NOT guarantee) the addition of
tests that violate the dictum.
Additionally, test failures must be easily reproducible for folks investigating
the test failure. Also, tests that assert correctness of unrelated code must not
stop progress on the authors patch.
This changes does not hinder reproducibility of test failures because the random
seed is printed in the logs before running each test. Developers attempting to
reproduce the failure locally can do the same via the following invocation
`--gtest_shuffle --gtest_repeat=<the count> --gtest_random_seed=<seed from failing run>`.
This change does introduce potential burden on patch authors that may see
failures in unrelated code as a newly failing shuffle seed is used on their
runs. To ameliorate this, we will formulate guidance for them to aggressively
mark such tests as disabled and file bugs to enable the same.
The test seed is intentionally kept low because it’s purpose is to test that
individual tests are repeatable. It must not be used as a replacement for
fuzzing.
* Do not pass a milliseconds::max() timeout that will overflow when converted
to nanoseconds
* Avoid holding the task_queue_mutex_ while calling glfwWaitEventsTimeout
* Use a signed type to hold the difference between a task's timestamp and
the current engine time
Fixes https://github.com/flutter/flutter/issues/40281
Makes the plugin registration structure consistent with macOS. This will
be used in generated plugin registrant files rather than a specific
implemenation class, so this helps unblock the creation of generated
registrants on Windows and Linux.
Manage resource and onscreen contexts using separate IOSGLContext objects.
FlutterView owns the onscreen context, and PlatformViewIOS owns the resource context.
Additionally, we now use the engine directly as a delegate instead of storing potentially dead runtime_controller.
Unit tests have been updated to include an engine restart check which would fail before the fix.
This fixes https://github.com/flutter/flutter/issues/40303
