Additionally create "_next" permutations for all of the test binaries
on Fuchsia, in order to test both code-paths.
Using the #define follow-up CLs can also create a flutter_runner_next
binary that does not contain any legacy integration code.
BUG: 53847
This reverts commit a7a25d3b57f2066798ef8cd43600588e4697c9cd and relands our reland https://github.com/flutter/engine/pull/17915.
Additionally, we fixed the cull rect logic in `OpacityLayer::Preroll` which is the root cause of https://github.com/flutter/flutter/issues/56298. We've always had that root problem before but it did not trigger performance issues because we were using the OpacityLayer's `paint_bounds`, instead of its child's `paint_bounds` for preparing the layer raster cache. A correct handling of the cull rect should allow us to cull at any level.
It also turns out that our ios32 (iPhone4s) performacne can regress a lot
without snapping. My theory is that although the picture has a
fractional top left corner, many drawing operations inside the picture
have integral coordinations. In older hardwares, keeping those
coordinates integral seems to be performance critical.
To avoid flutter/flutter#41654, the snapping
will still be disabled if the matrix has non-scale-translation
transformations.
This reverts commit b5aedb3 and relands #17712.
Fixesflutter/flutter#53288 and flutter/flutter#41654.
Together with #17791, this reland addresses some of Jim's concerns in the original PR #17712.
The major part of this PR is still the same as the original PR, and the performance / golden image impacts should be the same.
This avoids the possible matrix mismatch between RasterCache::Get and
RasterCacheResult::draw. See
https://github.com/flutter/engine/pull/17790 for an example that tries
to fix an earlier mismatch.
RasterCacheResult::draw constructs the device target rectangle by
calling SkRect::roundOut, which rounds down the left/top coordinates
and rounds up the right/bottom coordinates. The rounding can produce
a device rect whose width and/or height differs from the cache result
image's width/height by one pixel.
This caused regression in several benchmarks, including:
animated_placeholder_perf. Regression tracked in
https://github.com/flutter/flutter/issues/51776.
This reverts commit 01a52b9947054f57398f2aaa2b59e7d501506580.
If Rasterization fails, i.e. image.is_valid() is false, the cache might try rasterizing the image again on the next frame. Not only is this wasteful put might also prevent other pictures to be cached within the current frame budget.
RasterCache::Get() methods were not updating the RasterCache::Entry
access_count and used_this_frame fields, as is done in
RasterCache::Prepare(). This can result in onscreen images being evicted
from the cache as new entries are created (e.g. as new elements scroll
onscreen).
* Revert "Add flow test fixtures and tests (#13986)"
This reverts commit 620f5281b819f304e8e9e945222e26b17b087cc3.
* Revert "Dynamically determine whether to use offscreen surface based on need (#13976)"
This reverts commit a86ef946563b020108320bbfb974bf7343284fd3.
* Revert "Revert "Allow raster caching any layer subtree (#6442)" (#6506)"
This reverts commit c6e6da512a54c1bb33a584b117bcf300ce71b166.
* Use raw pointer for RasterCacheKey
So we won't depend on whether it's a std::unique_ptr or std::shared_ptr.
We first test this with OpacityLayer. This test alone (without retained rendering) should have ~30% speedup as we'll have fewer render target switches by snapshoting in the Preroll instead of saveLayer in the Paint.
In my local flutter_gallery transition perf tests, the average frame time drops from ~16ms to ~12ms.
https://github.com/flutter/flutter/issues/21756
gtest is an old version that predates the googletest and googlemock
merger, all tests should be using the newer googletest that's being
kept in sync with the upstream version.
gtest is an old version that predates the googletest and googlemock
merger, all tests should be using the newer googletest that's being
kept in sync with the upstream version.
* Revert "Revert "Reland "Run Flutter on iOS and Android with color correct Skia" (#3818)" (#3823)"
This reverts commit db8d8a9979901d05b011368226ad5bf61b1da13f.
* Fix test code to match internal API change
* Revert "Revert "Run Flutter on iOS and Android with color correct Skia (#3743)" (#3775)"
This reverts commit cfe70e07d386d6052267fe3772bbd641c8413a54.
* Enable sRGB on IO thread, too
* Add 4444 as a fallback rendering mode
* Use bare ptr to SkColorSpace (not sk_sp) in PrerollContext
* Run Flutter on iOS and Android with color correct Skia (#3716)
***Turns on color correct rendering for Android and iOS
***Communicates dst color space to raster cache
***Turns on color space aware image decoding
Test:
***color_testing_demo on Pixel XL
***flutter_gallery on iPad Mini and iPad Pro (haven't figured out how to run manual_tests on iOS)
TODO:
I needed to split up this CL somewhere. These are follow-up tasks.
***Make desktop backends color correct
***Make debugging tools (ex: encoding frames to png) preserve color space
***Investigate using UIKit API to allow iOS to fine tune color space of rendered content
* Fix pixel rounding error in the picture layer by first ensuring that
the texture for the image is at least as big as the next integer size
along each dimension and using kStrict_SrcRectConstraint while
drawing the same image. We already select the source subset by
looking at the cull rect of the picture.
* Decompose the transformation matrix into a series of operations that
generated the same to calculate the scale at which to rasterize the
picture. This make the rasterization scale resilient to
transformations that introduce a perspective component to the
resultant matrix.
* The scale in the decomposed matrix is now part of the key in the
cache.
* Raster cache images that could never be rasterized were still taking
part in the cache. Now, those entries are rejected early on. This
leads to the sweep after the frame iterating over fewer items.
* Added a unit test target.
