-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Material page transition is slow when we enable fade #13736
Comments
Specifically, this seems to cause a ~2x regression on the GPU side. |
cc @cbracken and @chinmaygarde for the engine side. @abarth was suggesting one trick we could use is noticing that a particular layer hasn't changed from frame to frame and not redrawing it when we change the opacity, or some such; I forget the precise details. |
The idea is to be able to cache intermediate layers (in this case the one that gets blended back into the main buffer) rather than just leaves as we do today. The framework could take each layer with a unique id (similar to the unique id we use for SkPicture). The compositor could then notice with a subtree had the same id as before and consider caching it. |
Can we turn the default back to "use opacity" in the meantime? I believe the perf hit is less bad than the current situation now. |
I'm happy to set the default to whatever you think is best. Please make sure you've tested it with it on and off on a low-end device before making a final decision though; the effect on low-end devices can be dramatic (as in, halving the frame rate, if the transition is only barely making 60Hz without the fade). |
I wonder if this report is the same thing as this bug: https://stackoverflow.com/questions/49145258/flutter-routing-stutter |
Unlikely since that example didn't turn on any opacity animations as far as I can tell. There are some complains on the Play Store as well. I wonder if we're missing anything with our transition benchmark tests (different Android devices for instance). |
This looks like a regression, reported by @RobertBrunhage here: #15294 |
cc @Hixie per email discussion, yes as a temporary solution it would be great to enable "use opacity" for Gallery until we have a fix for this. I took a quick look myself, and not quite sure how to do it. |
@mehmetf Roberto is currently out. Do you expect there are issues here that are specific to mulligan? Once you all achieve the desired frame-rate for your sample app/performance test (not sure what you're using to measure it), shouldn't we be OK too? |
@alanrussian Potentially. My understanding is that Gallery ships with the fading routes option because it is an acceptable fix. However, Roberto said the fading routes was still janky on the Mulligan app and thus was not a acceptable fix. That's why I requested Mulligan to measure and report performance (such as where frames are being dropped). |
We still have to look more into this but one specific issue for now: if you push a route with an autofocus form field it's really janky. I'm guessing the cause is the combination of the keyboard opening (which animates the size of the pushed screen) and the screen transition. cc @johnfesa |
@Hixie @HansMuller Why are we stalled on this issue? Is it because we don't have more evidence/use cases to go on? |
@mehmetf My understanding is that the fade transition is much faster now, but there's still room for further speedup. In particular, we're trying to enable retained layers. @chinmaygarde is actively working on that. Once it's done, I should be able to send a small patch to speedup animating the opacity. |
Removing customer blocker tag as per internal discussion. |
This continues to be our top priority for 1.0; we're not stalled, just working hard. :-) |
saveLayer is slow so we should avoid it as much as possible. If there are artifacts without saveLayer, then we should report that to Skia for the fix instead of slowing the performance with saveLayer. This PQ makes average rasterizer time drop from 25ms to 18ms in flutter_gallery transitions perf test on a Nexus 5X. This partially fixes flutter/flutter#13736 . We probably still need some work in the opacity layer to squize all the performance improvements.
The average frame time of page transitions on Moto G4 is now very close to 16ms (the last 10 measurements on our dashboard are between 15.5ms to 16.7ms and half of them are below 16ms). It is now much faster than when we disabled it (which was at about 35ms). So I think that we should be able to enable it by default. I'll leave the flag there until we implement the retained rendering to bring the frame time comfortably below 16ms. See flutter#13736
The average frame time of page transitions on Moto G4 is now very close to 16ms (the last 10 measurements on our dashboard are between 15.5ms to 16.7ms and half of them are below 16ms). It is now much faster than when we disabled it (which was at about 35ms). So I think that we should be able to enable it by default. I'll leave the flag there until we implement the retained rendering to bring the frame time comfortably below 16ms. See #13736
I'm closing this for now. The remaining work will be tracked in #21756. |
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
No description provided.
The text was updated successfully, but these errors were encountered: