Skip to content
Commit af501bca authored by Tony Mak's avatar Tony Mak
Browse files

Reduce the latency between the selection span is adjusted and the toolbar is shown

Results:
We measure the latency between Editor.startActionModeInternal is called
and FloatingToolbar.show() is called.

When there is only smart action (url)
Before: ~150ms
After ~30ms

When there are 5 smart actions (phone number)
Before: ~400ms
After: ~100ms

Before and after videos:
https://recall.googleplex.com/projects/ea8c4705-96bd-46f0-9f37-786708050727

Fixed a few issues:
1. updateAssistMenuItems() gets the Icons from TextClassification
   object, calls loadDrawable on them and creates the MenuItem
   objects loadDrawable() is slow, especially if we have a lot of
   smart action icons to load. Even worse, we are calling this
   function 4 times in a row when selecting something! 1 time from
   onCreateActionMode and 3 times from onPrepareActionMode.
   The fix here is to avoid reloading the drawable if it is the same
   text classification object.

2. From SelectionActionModeHelper, we call startActionModeInternal
before SelectionModifierCursorController.show()
Internally, SelectionModifierCursorController.show()
show the two selection handles  by calling startHandle.show() and
endHandle.show(). Apparently, each handle.show() call invalidates the
action model right after it is just created! This explains two of the
unnecessary onPrepareActionModel calls.

The fix is to call SelectionModifierCursorController.show()
before startActionModeInternal() is called.

3. Editor.startActionModeInternal() does not invoke
FloatingToolbar.show() right away.
There are two issues here.
a) Editor.startActionModeInternal() ends up calling
FloatingActionModel.repositionToolbar() which hopefully calls
FloatingToolbar.show(). Sadly, it is not the case
because mViewRectOnScreen is not set at that time. mViewRectOnScreen
is set in next onPreDrawCall() call.

b) When mViewRectOnScreen is finally set and calls repositionToolbar()
again , it still won't call FloatingToolbar.show() immediately
because we think that the toolbar is moving by comparing the previous
content rect and the current content rect. They are different because
the previous one is empty(it wasn't shown before). Becoz we think it is
moving, we schedule the FloatingToolbar.show() call after 50ms.

To fix a, we now update mViewRectOnScreen() right away wihout waiting
for the next onPreDraw call().
To fix b, when the previous content rect is moving, we don't consider
the toolbar as moving anymore.

Bug: 169043706

Test: atest android.widget.TextViewActivityTest
Test: atest
cts/tests/tests/textclassifier/src/android/view/textclassifier/cts/TextViewIntegrationTest.java
Test: atest
cts/tests/tests/widget/src/android/widget/cts/TextViewTest.java
Test: Smart select a phone number and then smart select a link.
      Make sure the smart actions menuitems are updated.
Test: Click on a smart linkify link. Then dismiss it by tapping outside.

Change-Id: I634b21ac7ed66a14883dc17e03ef006df5b3f223
parent 6b634145
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment