SpellChecker is exclusively called from the main UI thread and
there are no concurrency issues. As a result, the TextView's
wordIterator can safely be re-used in the parse() method.
Also reset the pool of SpellParsers on language change.
Change-Id: I1cc8a2750f21233754f006e40a81622730030ec8
In Recents in landscape, we were seeing blue flashes when scrolling; generally, almost every scrolling container should be delaying child presses to prevent this problem
A recent patch taking scroll into account was applied at the wrong
level. isVisible() expects positions that already take scroll into
account. isOffsetVisible() is where the initial bug was.
Cherry pick of 144415 from master.
Change-Id: I06ceebfb3d7b24aa4adba886c24fcf9d8dd39d2e
This reverts commit d224c88c48.
Based on Dianne's comments, this small optimization seems uncessarily
risky. I'll submit a new change where each SpellParser has its own
WordIterator to make this thread-safe.
Change-Id: Ic09fa656b00d284536e58f4cc7d26d5e26c3f3cf
Measuring line widths, glyph by glyph slows down the scrolling
process for long text (for some reason, width measure efficiency
is affectedi by text length, maybe because the whole text has to
be passed to JNI layers).
This optimization avoids this computation in the case where there
is no possible horizontal scroll.
Change-Id: I2082e3d0eedace1a86122a03e4b21f90f3bc8522
Limit each parse to batches of a few words, to keep the UI thread
responsive.
Possible optimizations for the future:
- SpellCheck in a thread, but that requires some locking mecanism
- Only spell check what is visible on screen. Will require additional
spans to tag the pieces of text.
Change-Id: Ibf8e98274bda84b7176aac181ff267fc1f1fa4cb
1. Now the NumberPicker has a max height and width for which is looks
good but can still shrink if there is not enough available space.
bug:5512787
Change-Id: Ieea88cafa8408e1d4160bab4bfe2b771bd79f7f8
Tweak to the logic to take account of margins when gravity = FILL is used and
there is a measurement dependency between the axes (as in mulit-line text).
Change-Id: I91b9143c2d5db41cb67dd641d5c7ea0b56cae7ff
A recent patch taking scroll into account was applied at the wrong
level. isVisible() expects positions that already take scroll into
account. isOffsetVisible() is where the initial bug was.
Change-Id: If2a5349555ec9e86e4295e819d5d9086f0adcdbd
parse() is called from the UI thread when text is changed, and in
that case it is safe to re-use the TextView's WordIterator.
It can also be called from the SpellCheckSession thread though
onGetSuggestions: use a local WordIterator in that case.
Change-Id: I596bff15cc8f997b9dc49598724450ac5c582101
This is a cherry-pick in MR0 of CL 141388 from master.
Bug 5488537
In case the span has been removed from the text since the popup
was showed, the delete action is a no-op.
Change-Id: Iec2aeaf03becd82ad44715d5c08bfaa8f62aa3fe
1. Some obsolte logic was placing invalid index in the array of
scroll wheel items which was resulting in failure to look its
string representation from the cache causing a NPE.
2. While editing the current value via the IME the middle item
of the scroll wheel was partially visible i.e. the user was
able to see a dimmed version of the old value intermixed with
the new one.
3. The logic for hiding the IME while poking a button i.e. starting
to use another way of changing the current value, was incorrect.
bug:5480205
Change-Id: I1c2c96402bd38bac1dec64ccc6b550410332b9d7
The code that initializes accessibility events was assuming the AdapterView
always has an adapter and this caused NPE. Now the right method of the view
is called to get the item count.
bug:5474162
Change-Id: I6c330dc2894477df9447a4ecfddc7bd62c575d59
The NotificationPanel was using views that had non-1 alpha
values set on them (permanently). This is costly in the GL
implementation and caused more rendering overhead, and worse
performance, than simple opaque views would.
The fix is to set the text color and ImageView drawable alpha
directly, without setting the View alpha property.
Change-Id: I381e0bd45bf45784b8e364a27a339e6583189a43
Bug 5379440. The spell check is now using the IME's language to
do the spell checking. Changing the input language triggers a
new spell check of the entire text.
Optimizations: ArrowKeyMovementMethod re-uses the TextView's
wordIterator, already set to the correct language.
One wordIterator shared by all SpellParsers in SpellChecker.
Cannot re-use TextView's because of concurrency issues.
With the current implementation, one has to type a new character
to see the new spell checking take place.
Change-Id: I0e460c0a6777548f89d03d6b68f3deea6606c17f
