I’ve decided to start a blog series documenting my workflow for performance investigation. Let me know if you find this useful and I’ll try to make this a regular thing. I’ll update this blog to track the progress made by myself, and anyone who wants to jump in and help.
I wanted to start with the b2g unlock animation. The animation is O.K. but not great and is core to the phone experience. I can notice a delay from the touch up to the start of the animation. I can notice that the animation isn’t smooth. Where do we go from here? First we need to quantity how things stand.
Measuring The Starting Point
The first thing is to grab a profile. From the profile we can extract a lot of information (we will look at it again in future parts). I run the following command:
./profile.sh start -p b2g -t GeckoMain,Compositor *unlock the screen, wait until the end of the animation* ./profile.sh capture *open profile_captured.sym in http://people.mozilla.org/~bgirard/cleopatra/*
This results in the following profile. I recommend that you open it and follow along. The lock animation starts from t=7673 and runs until 8656. That’s about 1 second. We can also note that we don’t see any CPU idle time so we’re working really hard during the unlock animation. Things aren’t looking great from a first glance.
I said that there was a long delay at the start of the animation. We can see a large transaction at the start near t=7673. The first composition completes at t=7873. That mean that our unlock delay is about 200ms.
Now let’s look at how the frame rate is for this animation. In the profile open the ‘Frames’ tab. You should see this (minus my overlay):
Alright so our starting point is:
Unlock delay: 200ms
Frame Uniformity: ~25 FPS, poor uniformity
In part 2 we’re going to discuss the ideal implementation for a lock screen. This is useful because we established a starting point in part 1, part 2 will establish a destination.