Hi friends, after a month working on it full-time, I managed to make arbitrary Flutter apps ~60FPS smooth regardless of how janky it originally was due to build/layout.
For demonstration, there is a 3-second video in GitHub README. You can also find more details in the "Benchmark" chapter, where I experimented it and see it runs at (roughly) full FPS, feel smooth, has zero uncomfortable janks, with negligible overhead.
There are two ways to use it: For common scenarios, just add six letters ("smooth"), such as using SmoothListView instead of ListView. For complex cases where you want customization, use SmoothBuilder and put things that you need to be smooth inside the builder (just like how you use Builder everyday, but smooth).
As for how it is implemented, I have written down a full chapter ("Design" chapter) in the documentation.
Story time: Indeed I have failed a ton of times before finding out this solution. The "literature review" section summarizes them so I do not repeat here. It is another ton of failures before the theory becomes truth. At around half a month I was almost going to give up, because it stuck at less than 40-50FPS instead of the perfect ~60FPS, and my theory seems does not consider the scenario after a janky frame properly at all. But later I managed to patch my theory to fix the problem (seen in "post draw frame" section of doc). After that I fixed many edge cases one by one, where each problem causes (for example) 1FPS drop, then finally reached near 60FPS.
Interesting. I still don't see a ELI5 explanation how you achieve this? If this fixes Flutter, why not put these changes in the main Flutter source? I'm a bit confused, if this is a 60 fps for free with some renaming, why is it that easy? Something feels fishy here. This is cool, dont get me wrong, but I just dont see how its "this" easy to fix jank/60 fps.
I will make an ELI5 explanation later when having time - you know, it is much harder to explain something ELI5 instead of discussing the tech details. There is a full long chapter about non-ELI5 explanation though.
> If this fixes Flutter, why not put these changes in the main Flutter source
I have been making a ton of PRs to Flutter :) I also discussed w/ Hixie on public discord channels about being into Flutter, but later we concluded that it is much easier to be a 3rd party package.
> I'm a bit confused, if this is a 60 fps for free with some renaming, why is it that easy ... Something feels fishy here.
Sorry what is "with some renaming"? Not get it, it is not renaming, but literally really ~60FPS.
You can see benchmark chapter for the details, or download and compile the app and run on your own phone and look at source etc. If you find it not ~60FPS, feel free to create an issue with your profiling data so I can see what bug it is.
> This is cool, dont get me wrong, but I just dont see how its "this" easy to fix jank/60 fps.
Hey this is not "this" easy - I have spent a whole full month without weekends and with a ton of failures! And please see the "design" chapter - a ton of work indeed. So it is never "easy".
For demonstration, there is a 3-second video in GitHub README. You can also find more details in the "Benchmark" chapter, where I experimented it and see it runs at (roughly) full FPS, feel smooth, has zero uncomfortable janks, with negligible overhead.
There are two ways to use it: For common scenarios, just add six letters ("smooth"), such as using SmoothListView instead of ListView. For complex cases where you want customization, use SmoothBuilder and put things that you need to be smooth inside the builder (just like how you use Builder everyday, but smooth).
As for how it is implemented, I have written down a full chapter ("Design" chapter) in the documentation.
Story time: Indeed I have failed a ton of times before finding out this solution. The "literature review" section summarizes them so I do not repeat here. It is another ton of failures before the theory becomes truth. At around half a month I was almost going to give up, because it stuck at less than 40-50FPS instead of the perfect ~60FPS, and my theory seems does not consider the scenario after a janky frame properly at all. But later I managed to patch my theory to fix the problem (seen in "post draw frame" section of doc). After that I fixed many edge cases one by one, where each problem causes (for example) 1FPS drop, then finally reached near 60FPS.