Deplorable GPU rendering profile only with just the cursor blinking

Question

This is a problem that has me struck with confusion. I was profiling an app I am developing and noticed that whenever I stopped scrolling a RecyclerView the GPU profile started accusing horrible stats. I could not understand why this was happening, nothing on the screen appeared to be updating until I noticed something changing behind the GPU profile graph in sync with the graph update.

It was the cursor blinking in an EditText view.

I could not believe that I had develop an app that would behave so horribly only when the cursor was blinking, so I investigated other apps, google apps and found out that the issue is present everywhere and it is not restricted to my app.

The following is a screenshot taken of just the cursor blinking inside the searchbox of the Gmail official app.

As you can see the GPU profile is unacceptable.

Is there anyway to fix this or avoid this issue? I recall testers complaining of battery drain when the app was open doing nothing, but I assumed at the time it was related to a bug that existed with a socket connection. Now when considering this problem and the testers often leave their phones on the same screen where a cursor is always blinking it's very likely the cause of the battery drain, so it would be important to reduce the impact that a simple blinking cursor has.

Do consider that I don't intend to rewrite the cursor nor change it's expected behavior, I'm simply trying to reduce the impact the blinking cursor has on the GPU.

Answer 1

I think that your issue was reported here: TextView cursor blink GPU rendering unusual as the description appears to match your flame graph.

The Google engineer that closed the issue as working as intended stated:

This is actually working as intended - since the CPU is at very low load (no animations running or any work being done), it's running at a very low frequency and the rare frames it does push out are very slow to render. That's fine though - there's no visible jank occurring, since continuous frames aren't being produced. Visible jank can only occur when there's a continuity of motion being interrupted. If there was motion though, the CPU would clock up, and the frames would render much faster.

You'll see the same thing when music apps update their scrubbers only once every second, instead of at 60fps. Frames take a long time, but it's a big savings on battery life.

While that doesn't answer the question of battery life, arguably the end user doesn't spend much time entering text and if the end user's attention changed away from the screen during text entry either device goes into idle/doze mode or the user would be using a different app, as opposed to a test device in a harness/test plan.

As rendering text is complicated it may help to read Android's Font Renderer by Romain Guy