Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: flutter/engine
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 89df726
Choose a base ref
...
head repository: flutter/engine
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 0ee413e
Choose a head ref
  • 3 commits
  • 30 files changed
  • 3 contributors

Commits on Mar 18, 2024

  1. [web] Avoid using js_util.{jsify,dartify}() in dart2wasm for conver…

    …ting to JS wrappers (#51375)
    
    The `js_util.jsify()` related code shows up in CPU profile of wonderous.
    
    => Any `SkwasmObjectWrapper` object invokes this logic in the
    constructor and dispose method.
    
    This PR
    
    * makes `DomFinalizationRegistryExtension` accept `JSAny` types instead
    of Dart types and internally converting
      => Callsites can call more precise `<>.toJS*` extension methods
    => Will avoids extra type checks on the objects when we can call
    `Object.toJSBox` directly
    
    * makes us use a `toJSWrapper` / `fromJSWrapper` which will not delegate to a recursive `jsify()` but simply externalize the wasm gc object
    => We cannot use `Object.toJSBox` due to it being slower to create JS
    boxes as it semantically does something different atm (see issue below)
    => Instead use conditional import of `dart:_wasm` which provides the
    necessary primitives
      => Similar for going from JS to Dart.
    
    * Avoid converting from Dart object to `JSAny` more than needed
    (we did the operation twice for each registration and once for
    unregistration)
    
    Issue dart-lang/sdk#55183
    mkustermann authored Mar 18, 2024
    Configuration menu
    Copy the full SHA
    fda5c69 View commit details
    Browse the repository at this point in the history
  2. Reverts "[Fuchsia] only download fuchsia deps when necessary (#51439)" (

    #51500)
    
    Reverts: #51439
    Initiated by: zijiehe-google-com
    Reason for reverting: broke dart->flutter roller due to the expected licenses not being included without `download_fuchsia_deps` in `.gclient`.
    Original PR Author: zijiehe-google-com
    
    Reviewed By: {zanderso}
    
    This change reverts the following previous change:
    This is a quick follow up of #51072 to only download fuchsia deps (via download_fuchsia_deps gclient arg) when necessary. Considering the pr/51072 is very huge, keeping these condition changes in a separate change would be cleaner.
    
    The wiki has been updated already since setting the download_fuchsia_deps gclient arg explicitly won't break the existing workflow. I also mentioned in the wiki that building and running fuchsia needed a linux box (an explicit assertion in the with_envs.py).
    
    Bug: http://b/40935282
    
    [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
    auto-submit[bot] authored Mar 18, 2024
    Configuration menu
    Copy the full SHA
    3afc7b1 View commit details
    Browse the repository at this point in the history
  3. A native Android unit-testing harness. (#51479)

    Sets up rules to create an APK that is comprised of solely native code. Existing executable targets (like GTests) can then use this to run on Android devices while having access to activities, windows, etc.. This allows for broader test coverage. Basically, anything that needed an ANativeWindow could only be tested in an integration test.
    
    Executables that need access to the native activity must provide an implementation of `NativeActivityMain` that returns a custom subclass of `flutter::NativeActivity`. The `native_activity_apk` reads like an `executable` or `shared_library` target. Just one that packages that executable in an APK.
    
    The APK is built using the Android Tools and does not use Gradle. Creating a new APK after invalidating some code takes ~200ms on my machine. The edit, compile, run cycle for only a tiny bit worse than testing on the host.
    
    Builds on top of this new infrastructure to create a `GTestActivity` that runs an existing test suites. This works really well except the GTest suite logs to `STDOUT` whereas the engine logs to `logcat`. To quickly work around this, a custom test status listener has been wired up. This only displays the test results to logcat today but a similar mechanism can be used to talk to the test runner in the host. I will wire this up in an upcoming patch as there is no hooks into this from CI right now.
    
    Creates an APK variant of the `impeller_toolkit_android_unittests` harness.
    chinmaygarde authored Mar 18, 2024
    Configuration menu
    Copy the full SHA
    0ee413e View commit details
    Browse the repository at this point in the history
Loading