Transient state is temporary bookkeeping that Views need to perform
that the app should not need to be aware of. Examples include text
selection regions and animation state.
Transient state is a problem for AdapterViews like ListView that do
view recycling. Unless the app takes responsibility for tracking and
restoring transient state as if it were a part of the adapter's data
set, it cannot correctly recycle views. Selections disappear when an
EditText is scrolled out of sight and animations seem to play on the
wrong views.
Views can now flag themselves as having transient state. (As the name
implies, this should be a temporary condition.) If a ViewGroup
contains a child with transient state, that ViewGroup also has
transient state.
AbsListView's recycler now tracks views with transient state
separately. Views with transient state will be retained, and until a
data set change occurs the same view will be reused for that position
instead of calling the adapter's getView() method.
The API to set and check transient state is currently hidden.
Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
This optimization allows us to quickly skip operations that lie
entirely outside of the known bounds of a display list. Because
of ViewGroup.setClipChildren, we must keep the operations recorded
in the display list. setClipChildren(false) is however a very
uncommon operation and we will therefore often benefit from this
new optimization.
Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
Set a barrier on traversals.
Vsync is still not enabled by default in this patch so there
should be no observable effect from these changes.
Change-Id: Ie12081b95a8f1e81ed686edf747cc62f2e044b7e
This change makes it much easier to make sense of the messages that
get posted to the ViewRootImpl's handler by encapsulating their point
of dispatch within the ViewRootImpl itself.
As part of this change, the View.AttachInfo now carries a reference
to the ViewRootImpl itself, which simplifies some code that used
to try to find the ViewRootImpl by getting the root view's parent.
In principle, it might have been nice to hide the ViewRootImpl from
the View hierarchy but in practice the two were coupled in many ways.
Change-Id: I51ebccdf5f8c8c505cd6f17cdf594174d041dc54
This adjust various paths through InputMethodManager so that the flow
in switching focus from one application to another is cleaner, resulting
in less work being done, resulting in it being able to happen quicker.
Some of the changes here avoid doing stuff when not needed, such as when
we are told to unbind but are not currently the active input. A big part
is also a change to the flow when a window receives input. Previously
this would first do a checkFocus() which would tell the input method to
switch focus to whatever view has focus in the window, followed by the
windowGainedFocus() call telling it the window had gained focus. This
would result in extra work because the input method service would first
handle the focus switch, seeing the IME is currently displayed, so the IME
would remain up and reset its focus to the new view. The app would
immediately then tell it about the window, causing the service to find out
the IME should be hidden and telling the IME, but the IME couldn't hide
itself until it had first take care of switching its input.
There is the definite potential of this breaking IME showing/hiding in
cases depending on the order things may be relying on them to happen. I
haven't seen any problems with a brief trip through the UI.
Change-Id: I8494cbd6e19e2ab6db03f2463d9906680dda058b
There is really no point disposing the display event receiver
anymore. Moreover, it's hard to choose a good time to do it
since the Choreographer only supports one-shot callbacks now.
So let's made the code simpler.
Bug: 5721047
Change-Id: I8533a54e93a787e0ca30d99a1f1eea85534b13b9
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
Also clean up the Choreographer so that it doesn't directly extend
Handler and so that it doesn't schedule animation or drawing unless
there are listeners or callbacks attached.
Bug: 5721047
Change-Id: I35350c8d41d4fa3f8c8c7bc43edd82e581b55a68
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
Applications sometimes crashed on exit due to the display event
receiver pipe apparently being closed while still a member of the
Looper's epoll fd set.
This patch fixes a few different possible races related to
the display event receiver lifecycle.
1. The receiver used to play a little dance with the Looper,
registering and unregistering its callback after each vsync
request. This code was a holdover from a time before the
surface flinger supported one-shot vsync requests, so we can
get rid of it and make things a lot simpler.
2. When the Choreographer is being accessed from outside the UI
thread, it needs to take great care that it does not touch
the display event receiver. Bad things could happen if the receiver
is handling a vsync event on the Looper and the receiver is
disposed concurrently.
3. It was possible for the Choreographer to attempt to dispose
the receiver while handling a vsync message. Now we defer disposing
the receiver for a little while, which is also nice because we
may be able to avoid disposing the receiver altogether if we find
that we need it again a little while later.
Bug: 5974105
Change-Id: I77a158f51b0b689af34d07aee4245b969e6260d6
This tool lets you visualize the time it took, in ms, to:
- Build display lists ("Draw" phase)
- Process display lists ("Process" phase)
- Swap GL buffers ("Execute" phase)
To use this tool:
- adb shell setprop hwui.profile true
- adb shell dumpsys gfxinfo <process name>
- Copy the profile data and paste it in a spreadsheet
- Generate a graph (stacked graph) and enjoy
Change-Id: I7840c0ea0f153550425aa798e3ada2f357688cf5
Some of the ongoing and upcoming jank work involves having
Views optimize their rendering. For example, it would be more
efficient for native display lists to be able to redraw themselves with
updated transform/alpha properties than it would be to do it the
way we do now, which causes view hierarchy invalidation and display
list recreation.
In order to do this, we need to push more intelligence for view
rendering into the Views themselves, rather than the complicated
mechanism we have now of ViewGroup handling some View properties
(transforms and alpha) and the Views handling the rest of their
rendering.
The first step toward this is to take the current drawChild() method
and push it into a new, package-private method in View that does the
same thing.
Future checkins will refactor the code further, simplifying it and
eventually optimizing around view property changes.
Change-Id: Id44b94536fc3ff80b474db7ef06862f4f51eedce
This change allows layouts to be notified of changes to LayoutParameters that have occurred
between layout operations.
If an assignment is made to the fields of LayoutParams instances that are already in use,
cachced data may become inconsistent with the new values. For complex layouts, like
GridLayout, in which the layout parameters define the structure of the layout, caching
could have caused ArrayOutOfBoundsException to be raised without this change. This case is
rare in normal code as initialisation is typically performed once. Its nevertheless possible
and much more likely in environments like design tools where layout parametrs may be being
edited on the fly.
Prevent errors as follows (belt and braces):
1. Change javadoc to request that changes to the fields of LayoutParams be accompanied with
a call to View.setLayoutParams(). (This calls requestLayout() which was what the previous
javadoc advised.) Provide a (for now, private) hook for layouts with caches to receive notification
of such calls so they can invalidate any relevant internal state.
2. For GridLayout, we cannot clone layout parameters as traditional Java grids do without retaining
two complete copies because of the public getLayoutParameters() method on View. Retaining two
copies is wasteful on constrainted devices. Instead, we keep just one copy and compute a hashCode
for the critical fields of a GridLayout's layoutParams. The hashChode is checked it prior to all
layout operations; clearing the cache and logging a warning when changes are detected, so that
developers can fix their code to provide the call to setLayoutParams() as above.
Change-Id: I819ea65ec0ab82202e2f94fd5cd3ae2723c1a9a0
To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.
The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.
With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
This allows Music2 and other media apps to control master volume without changing their code
Bug: 5567694
Signed-off-by: Mike Lockwood <lockwood@android.com>
