This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail.
Below is the description from the original PR:
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.
* Workaround for canvas element lacking support for 3d setTransform
* update golden test
* Add webkit workaround
* Implement DOM rendering for perspective
* cleanup
* update goldens lock
* Add check for shader and filtermask for dom use
* Fix svg viewBox. Move zIndex check to bitmap canvas
* Fix null check warning
* Fix scene_builder zIndex=-1 test to force canvas usage
* Add blendmode handling for DOM mode
* Update maxdiff and golden locks
* Remove unused import
* Add drawcolor/drawpaint test. Fix bounds for drawColor/drawPaint
* update golden locks
* adjust drawColor for dpr
* Update test to use canvas
* Fix toDataUrl NNBD
* Update Picture.toImage to use canvas to obstain image data
* Remove write:true from golden calls
* Add fill-rule for _pathToSvgElement
* Update golden locks
* Fix sceneBuilder pushClip / add missing clipBehaviour
* Fix test now that clipping works correctly
* move overflow handling for tests into DOMClip.addOverflow
* Add clipRect to test to keep render inside bitmap canvas area
* Update compositing test, fix drawColor coordinates
* update golden locks
* Skip test for matchGolden infra fail
* update golden lock
* merge
* update maxdiff for text over canvas
* update golden diff
* update paint spread bounds maxdiff
* update paint spread maxDiff
* Revert "Fix documentation build for window changes. (#21780)"
This reverts commit 931a04683d6eb49fc92059b2384ac5b1618d5422.
* Revert "Migration to PlatformDispatcher and multi-window (#20496)"
This reverts commit 85b0031f73544e448354047dc6a236c0b0808252.
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.
* Move shader.dart into shaders directory
* Add Shader builder basic structure and decls
* rewrite drawVertices with ShaderBuilder
* Fix in parameters in fragment shader to use varying for webgl1
* change from build_runner to dart2js
* add internalBootstrapBrowserTest to some of the tests
* add internalBootstrapBrowserTest to all remaining tests
* make tests build in paralel. Total time dropped from 586 to 177 seconds for 8 core MacBook
* change isolates with pool
* fixing analysis errors
* skipping canvaskit tests for ios-safari
* copy image files to the build directory
* adding internalBootstrapBrowserTest to newly added tests
* add internalBootstrapBrowserTest to faling path iterator test
* necessary changes to make chrome windows work
* in windows test in chrome instead of edge. our edge code was for legacy edge
* do not run golden unit tests on Windows LUCI bots for now
* addressing reviewer comments. Adding a method for deciding when to run integration tests.
* remove lines that I forgot to remove
* fixing analysis error. add issue for todo
* add bootstap to a test file
* adding bootstrap to another test
* add internalBootstrapBrowserTest to a golden test
* return test result in bat file. use archieve package to unzip
* fixing logs for chrome_installer
* use archieve and archieve entity instead of dynamic
* adding comments for windows platform archieve part
* addressing reviewer comments
* change readme file
* change the version of simulator. luci bots only has 13.0
* skip failing pointer binding tests
* skip path_metrics (canvaskit) and a method from surface_test
* fix analyzer errors
* remove extra added touch event context test
* removing left overs for screenshot debugging
* apply reviewers suggestion for skipping tests
This change converts all Float64List matrices to Float32List at the dart:ui interface boundary. Internally, it only uses Float32List. Float32List requires less memory and is orders of magnitude faster to allocate, and it has sufficient precision as Flutter mobile engine and Skia use 32-bit floats anyway.
This change speeds up frame preroll by 50% on the bench_card_infinite_scroll benchmark.
For more details on Float64Array allocation in JS (which backs Float64List in Dart) see the following:
https://bugs.chromium.org/p/v8/issues/detail?id=9199https://bugs.chromium.org/p/v8/issues/detail?id=2022
