Assigned
Status Update
Comments
si...@google.com <si...@google.com> #2
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.
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> #3
Turns out, we already had a tracking bug for this issue, will follow up on that other one.
du...@gmail.com <du...@gmail.com> #4
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> #5
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> #6
Note: based on previous information about majority of time being spent in DynamicLayout$Watcher, and also what mentioned in
"Strangely, typing INTO the document was EXTREMELY slow. But hitting the backspace was maybe 130% of normal speeds"
It might be
si...@google.com <si...@google.com> #7
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)
Description
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."