85b0031f73
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window. The design doc for this change is here. The major changes in this PR: Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class. Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton). Next step after this PR lands: Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first. The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
Scenario App
This folder contains e2e integration tests for the engine in conjunction with a fake dart:ui framework running in JIT or AOT.
It intentionally has no dependencies on the Flutter framework or tooling, such that it should be buildable as a presubmit or postsubmit to the engine even in the face of changes to Dart or dart:ui that require upstream changes in the Flutter tooling.
Adding a New Scenario
Create a new subclass of Scenario and add it to the map in main.dart. For an example, see animated_color_square.dart, which draws a continuously animating colored square that bounces off the sides of the viewport.
Then set the scenario from the Android or iOS app by calling "set_scenario" on platform channel.
Running for iOS
./build_and_run_ios_tests.sh
iOS Platform View Tests
For PlatformView tests on iOS, you'll also have to edit the dictionaries in AppDelegate.m and PlatformViewGoldenTestManager.m so that the correct golden image can be found. Also, you'll have to add a GoldenPlatformViewTests in PlatformViewUITests.m.
Generating Golden Images on iOS
Screenshots are saved as
XCTAttachment's.
If you look at the output from running the tests you'll find a path in the form:
/Users/$USER/Library/Developer/Xcode/DerivedData/Scenarios-$HASH.
Inside that directory you'll find
./Build/Products/Debug-iphonesimulator/ScenariosUITests-Runner.app/PlugIns/ScenariosUITests.xctest/ which is where all the images that were
compared against golden reside.
Running for Android
The test is run on a x86 emulator. To run the test locally, you must create an emulator running API level 28, using an x86_64 ABI, and set the following screen settings in the avd's config.ini file:
hw.lcd.density = 480
hw.lcd.height = 1920
hw.lcd.width = 1080
lcd.depth = 16
This file is typically located in your $HOME/.android/avd/<avd> folder.
Once the emulator is up, you can run the test by running:
./build_and_run_android_tests.sh
Generating Golden Images on Android
In the android directory, run:
./gradlew app:recordDebugAndroidTestScreenshotTest
The screenshots are recorded into android/reports/screenshots.
Verifying Golden Images on Android
In the android directory, run:
./gradlew app:verifyDebugAndroidTestScreenshotTest
Changing dart:ui code
If you change the dart:ui interface, remember to point the sky_engine and sky_services clauses to your local engine's output path before compiling.