Emoji EditText performance [215391131]

Assigned

Bug

Status Update

No update yet.

Description

si...@google.com

created issue #1

Jan 19, 2022 07:18PM

forked from b/189737781#comment3:

"This is a massive issue in 2022 w/Android 12. The edittext in question (actually a AppCompatMultiAutoCompleteTextView) is being used in a text editor app and is fairly large/full screen.

Any (soft) keyboard press is causing a 1 second delay before that character appears. Not just emojis, but ANY character typed to the screen has a HUGE processing delay.

Via the profiler, the problem is tracked to EmojiCompat.process-- it is consuming 491ms per KEYPRESS. androidText.dynamicLayout$ChangeWatcher.reflow is consuming most of this time.

Disabling all emoji input via filter instantly returns the edittext to a responsive usable state.

Please fix this quickly as it no doubt will affect any app that uses a larger edittext. I tried w/dependency on androidx.emoji2:emoji2:1.1.0-alpha01 in gradle.build and without."

Comments

si...@google.com <si...@google.com> #2Jan 19, 2022 08:42PM

Reassigned to du...@gmail.com.

This actually has nothing to do with NavHostFragment, but is the behavior of NavController's setGraph().

When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.

If you were to instead use:

NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));

Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.

You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.

si...@google.com <si...@google.com> #3Jan 19, 2022 08:47PM

Turns out, we already had a tracking bug for this issue, will follow up on that other one.

du...@gmail.com <du...@gmail.com> #4Jan 19, 2022 09:25PM

Thank you for promptly replying to my report. You are right that the issue you've just mentioned is similar to mine. I shall continue observing the progress over there.

du...@gmail.com <du...@gmail.com> #5Jan 19, 2022 09:31PM

To address #3 directly-- it didn't matter what type of character was typed. Any text entered (spaces, random letters, or pasted text) would sit a moment, then stamp out slowly. Sometimes groups of text would be processed together. So you'd tap out "HELLO" and with a pause between letters it would be H... E... L... L... O on a 1/2 second delay. Or if you typed them quickly you might see the HEL and then LO in a clump after the delay. Carriage returns behaved the same way, but as I mentioned, backspaces would be much faster.

si...@google.com <si...@google.com> #6Jan 21, 2022 04:36PM

Reassigned to an...@google.com.

Note: based on previous information about majority of time being spent in DynamicLayout$Watcher, and also what mentioned in comment#4

"Strangely, typing INTO the document was EXTREMELY slow. But hitting the backspace was maybe 130% of normal speeds"

It might be SpannableBuilder.java handles deletes well but not inserts at that level. The reason why we added SpannableWatcher was very much related to delete operation being extremely slow at the time.

si...@google.com <si...@google.com> #7Jan 21, 2022 05:15PM

for your use case, very long edit text is not a surprise to have some issues with Spans. It is possibly more related to text having spans rather than the code in EmojiCompat.

I still suggest to turn off emojicompat for the EditText that contains the very large text only (rather than the whole app)

Issue 215391131