Deplorable GPU rendering profile only with just the cursor blinking
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.

add a comment |
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.

add a comment |
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.

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.


asked Jan 3 at 1:30
ShadowShadow
91041437
91041437
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54015268%2fdeplorable-gpu-rendering-profile-only-with-just-the-cursor-blinking%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
add a comment |
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
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
add a comment |
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
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
answered Jan 3 at 5:14
Morrison ChangMorrison Chang
8,26932649
8,26932649
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
add a comment |
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
Awesome, thanks for the context explanation as well. I think I can be glad knowing that it shouldn't be a cause for battery drain after all, wouldn't want having one of those and not be able to fix it.
– Shadow
Jan 3 at 6:30
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54015268%2fdeplorable-gpu-rendering-profile-only-with-just-the-cursor-blinking%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown