This makes sure the frame timings recorder and vsync waiter implementations get
the correct refresh rate if or when it adjusts at runtime. This should be OK
because we'll only query the refresh rate when the display metrics actually
change, which is much less frequent than every frame. I experimented with an NDK
implementation in the previous patch, but that vastly restricts the API levels
we can support, and currently on API 30 and 31 it just calls Java methods
through JNI anyway.
I've refactored the way Display updates are reported so that AndroidDisplay can
just dynamically get the refresh rate correctly. These values are used by a
service protocol extension and by some Stopwatches on the CompositorContext.
See also #29765Fixesflutter/flutter#93688Fixesflutter/flutter#93698
It changes master branch with main to prepare for the migration.
This change will be landed in synchronization with changes to modify
the engine default branch to main.
Bug: https://github.com/flutter/flutter/issues/90476
The initial implementation tried to leverage the fuchsia.git approach to
adding resources via GN template, but the GN SDK does not use the same
format or approach. This PR adds the snapshot resource in the way the
GN SDK expects.
The integration test works in debug/jit mode only, and building in
`profile` and `release` modes was not working, breaking some builders.
The workaround was to disable the test.
This PR will enable release/aot mode so it will build, and unblock both
the debug-mode version of the test (tested by CI) and release mode
builds of the repo.
Due to the request to unblock, this PR does not yet build packages in
`profile` mode that will run in Fuchsia, but it should at least build
without errors. Ongoing work is in progress to also support running in
release mode.
* Add new channel updateEditingStateWithDelta
* Fix formatting
* Fix formatting
* Fix formatting
* Add equality case
* formatting
* Implement TextEditingDelta class to encapsulate delta logic
* Formatting
* Also send new composing/selection along with delta
* Utilize an ArrayList of TextEditingDeltas to take into account batch editing
* clear batch deltas when editing state is updated by framework, we don't want to collect deltas from the framework because they have already been applied to the value on the framework side
* fix formatting
* formatting
* formatting
* Add enableDeltaModel flag to choose between updateEditingValue and updateEditingValueWithDeltas
* Add autofill support for delta model
* formatting
* update
* Fix issues with composing region
* formatting
* Remove
* Fix out of bounds error when textfield is initialized with text
* Clean up logs
* formatting
* update licenses
* Fix deletion issues
* formatting
* delta -> deltaType
* updates
* formatting
* formatting
* Fix logs
* Add tests for TextEditingDelta
* formatting fixes
* remove unused imports
* Fix return type for getDeltaType
* Fix tests
* Fix ListenableEditingStateTest
* formatting
* Fix typo
* Add test for deltas when setComposingText
* formatting
* Updates to test
* fix typo
* formatting
* Verify all properties of delta for test
* formatting
* Add VisibleForTesting import
* fix test
* fix formatting
* fix tests
* fix tests
* fix tests
* updates for tests
* remove ide made file
* Fix more tests
* Fix TextEditingDelta tests
* Add test for verifying delta is generated on setComposingText
* Add TextInputPlugin tests for replacement and deletion deltas
* formatting
* formatting
* Capture delta on setSpan and clear deltas when generated from the framework and when we skip updating the framework
* fix formatting
* update tests to reflect new clear batch delta calls
* Make deletion inline with platform
* fix tests
* Address reviewer comments
* formatting
* fix tests
* fix tests
* move delta inference to framework
* update tests
* formatting
* fix tests
* Formatting
* get -> extract
* More tests and address reviewer comments
* clean up logs
* Address reviewer comments
* formatting
* formatting
* Remove testing constructor
* send as deltas
Bug: fxb/79871
The code is still using the CFv1 implementation, so this should not affect the existing behavior.
For this version of the PR, I forked the existing DartComponentController. There were a few reasons for this:
Reduces the chance of the change breaking existing tests during Fuchsia GI.
Makes the V2 version of the DartComponentController simpler to read.
Makes it easier to switch over to using the V2 version of the DartComponentController once the migration is ready to happen (less cleanup).
The rate of changes to the DartComponentController is slow so there shouldn't be much maintenance required for the fork.
Changes to the DartRunner itself will happen in a follow-up PR - this PR only verifies that the ComponentController builds.
Relands GN and C++ changes for #27226 after rollback in #28036.
The multiprocessing package relies on the win32 `WaitForMultipleObjects`
call, which supports waiting on a maximum of MAXIMUM_WAIT_OBJECTS
(defined by Windows to be 64) handles, processes in this case. To avoid
hitting this, we limit ourselves to 60 handles (since there are a couple
extra processes launched for the queue reader and thread wakeup reader).
When left unspecified, the multiprocessing module defaults this value to
os.cpu_count(), so this error is triggered only on machines with > 60
cores.
See: https://bugs.python.org/issue2690
Bug: https://github.com/flutter/flutter/issues/90085
