You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 2, 2023. It is now read-only.
I'm am currently investigating using AsyncDisplayKit with ASCollectionView. I want to benchmark my best effort with both the conventional approach and ASCollectionView. I imagine FB has performed various benchmarks over the course of this project and was hoping to gain some insight as to the best approach toy validate smoothness.
The core animation instrument is not very useful. It only records FPS every second whereas I would like to know how what was happening every time a frame was dropped. My current approach is to autoscroll the collection view with a recursive function and setContentOffset:animated to eliminate human error. Then use the CA tool and just ensure the FPS is higher in the async case while ensuring the main thread activity is lower. In my sync case, the main thread is 94 % running time while the async main thread running time is 24%. I know that the system will not draw at 60 FPS if it does not have to so I don't know if I am really dropping frames. There must be a cleaner approach than this.
Geoff.
The text was updated successfully, but these errors were encountered:
@geoffmacd This is a good question and I wanted to answer it when I first saw it submitted way back in January — sorry I never got around to it!
The mechanism I've used is as simple as manually profiling your app (Time Profiler in Instruments). Then look for time on the main thread. Any time over about 10ms, especially if you know it will happen within a single runloop (e.g. call stack growing and then collapsing back to the base) will cause frame drops for scrolling, gestures, and physics-simulating animations.
The FPS measurement is not very useful because you may be holding a pretty high average FPS, but then drop a bunch of frames together; or only drop one frame per second, but it still feels bad. Basically FPS measurement does not correlate well with the human perception of the user experience.
Hey all,
I'm am currently investigating using AsyncDisplayKit with ASCollectionView. I want to benchmark my best effort with both the conventional approach and ASCollectionView. I imagine FB has performed various benchmarks over the course of this project and was hoping to gain some insight as to the best approach toy validate smoothness.
The core animation instrument is not very useful. It only records FPS every second whereas I would like to know how what was happening every time a frame was dropped. My current approach is to autoscroll the collection view with a recursive function and setContentOffset:animated to eliminate human error. Then use the CA tool and just ensure the FPS is higher in the async case while ensuring the main thread activity is lower. In my sync case, the main thread is 94 % running time while the async main thread running time is 24%. I know that the system will not draw at 60 FPS if it does not have to so I don't know if I am really dropping frames. There must be a cleaner approach than this.
Geoff.
The text was updated successfully, but these errors were encountered: