Repository navigation
demo_launcher scrolling slow on Galaxy S5 #118
Description
Sunday Aug 02, 2015 at 06:44 GMT
Originally opened as https://github.com/flutter/engine/issues/423
I've been closely following this project. At the Dart Summit talk, very high performance numbers were shown. When I load the sample app from the play store onto my Galaxy S5, or any of my co-workers devices I see fairly low frame rate. The frame rate is consistent, but it looks to only be around 15-20 fps. (The asteroids game sample appears to have very good frame rate though).
Do the original performance aspirations of 120 fps still seem feasible? Does the team feel there are optimizations that can be done to the current engine to increase the current performance significantly?
Activity
FlutterIssues commentedon Nov 9, 2015
Monday Aug 03, 2015 at 16:36 GMT
Yes.
Yes. Currently we are drawing every pixel of every frame from scratch. We'll eventually cache some pixels and re-use them from previous frames. We're purposefully waiting to add caching to the graphics pipeline because we want to see how far we can push the system in its current configuration.
FlutterIssues commentedon Nov 9, 2015
Tuesday Aug 04, 2015 at 16:06 GMT
c7f9c68 should improve scrolling performance on the demo_launcher by 3x. We'll need to check an S5 with the next release of SkyDemo to see if that fixes this issue.
FlutterIssues commentedon Nov 9, 2015
Thursday Oct 22, 2015 at 23:47 GMT
I believe we scroll much faster than when this issue was filed, so I'm going to mark this issue as fixed. Thanks!
FlutterIssues commentedon Nov 9, 2015
Thursday Oct 29, 2015 at 23:52 GMT
@abarth You can keep this closed if you want, but scrolling is still pretty laggy on the stock sample with the samsung s5, and also the nexus 5x I just tried it with too. After a while it seems to smooth out, but it takes some time.
FlutterIssues commentedon Nov 9, 2015
Friday Oct 30, 2015 at 00:12 GMT
Ok, I've re-opened this issue.
Hixie commentedon Dec 11, 2015
If it smooths-out after a while, it's probably Dart optimising the code over time.
sethladd commentedon Dec 12, 2015
I just profiled the Stocks app, after a cold start.
Most frames are > 16ms when running in checked mode.
In production mode, here's what I see:
Many frames are < 16, but you can see some that are bigger than 16.
After warming up the VM (scrolling up and down about 6 times), here's what I see:
I only see one long frame (oddly, right after I started tracing) and the rest are around 6ms
abarth commentedon Dec 12, 2015
We intentionally do lots of expensive work in checked me to catch errors. We could have an intermediate mode that had type checking but skipped the expensive checks, but that might just be more complexity.
The cold production mode trace looks pretty typical for our system today. Background compilation will helpfull remove the green blocks, which is where a lot of the variance is coming from.
The warmed up trace look pretty typically too. Once the VM warms up, we do a lot better.
Some tips:
flutter tracecommand to generate the traces instead of observatory, you'll also get tracing from the GPU thread, which can help you understand how we're doing on that side as well.@chinmaygarde is working on getting all the trace events into observatory. He's got some local patches that make it possible. I'm not sure what's blocking landing them or what the bug number tracking that work is.
chinmaygarde commentedon Dec 12, 2015
We are tracking this in #861
eseidelGoogle commentedon May 13, 2016
Performance should be much better by now. We also recently introduced --release and --profile modes to
flutter runandflutter build. Unfortunately they only work on Android built from Linux, but iOS and Android from Mac support should be landing within the next couple days. Regardless, I would expect these performance concerns to have been addressed in the last 6 months. :)Please re-open if you don't agree!
add a build rule for libwebp (flutter#118)
github-actions commentedon Aug 17, 2021
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
flutter doctor -vand a minimal reproduction of the issue.