The new DisplayList properties functionality does not currently handle Animation
(android.view.animation) functionality, so we fall back to the previous approach
of redrawing the DisplayList when an Animation changes alpha/transform data for
a View. The DL code was not, however, correctly using that logic, so that
the Animation transform information was being ignored, or at least not set
correctly on the DisplayList during redraws.
This fix accounts for Animation changes and sets up the DisplayList correctly.
Change-Id: I9f6e0382b05d0627f4779f30e74641dedcc77f82
A new test had been added to performDraw to provide an early return if
the screen was off. Drawing should have proceeded however if
mReportNextDraw is set. Otherwise views that turn on the screen (such
as the alarm) are not shown.
Fixes bug 6168158.
Change-Id: If9013d9dbd39d60ee1de8aeb3e0c1facbc5a7db5
1. The number picker no longer shows up and down arrows, it
has only three touch targets which are the currently selected number
in the middle with a lesser one above and greater below, now what
you touch is what you get, flingability and long press are still
supported.
2. Removed the restriction for a View with an AccessibilityNodeProvider
to not have any concrete children. If the View has a provider, then
this provider is responsible for creating the AccessibilityNodeInfos
for all its descendants, concrete and virtual. The number picker is
a good example for such a case - it has a concrete input view and
two virtual buttons as its children. This is a safe change since
this behavior has not been released.
3. This patch also fixes bug where the number picker is stretched too
much in the Theme theme.
bug:6177794
bug:5728294
Change-Id: I5fb370fe0b864a156f5f2aaf2de5f55f6b6d4e84
This CL simply enables DisplayList property functionality. The code for
this feature is already there, but it's been disabled by default pending further
testing and analysis. This change sets these build-type flags to true
so that all hw-accelerated apps will now use DisplayList properties by default.
In particular, this feature enables a fast-path for changes that affect the
handful of View properties involved in animations (alpha, translationX, etc.).
Setting these properties now gets propagated to the native DisplayList associated
with the View, avoiding costly recreation of the SDK-level DisplayList and
also enabling faster invalidation of the view hierarchy.
Change-Id: Ic99c8f28fa9183f2e54e9e4860b333eb9c540f7c
1. The number picker no longer shows up and down arrows, it
has only three touch targets which are the currently selected number
in the middle with a lesser one above and greater below, now what
you touch is what you get, flingability and long press are still
supported.
2. Removed the restriction for a View with an AccessibilityNodeProvider
to not have any concrete children. If the View has a provider, then
this provider is responsible for creating the AccessibilityNodeInfos
for all its descendants, concrete and virtual. The number picker is
a good example for such a case - it has a concrete input view and
two virtual buttons as its children. This is a safe change since
this behavior has not been released.
3. This patch also fixes bug where the number picker is stretched too
much in the Theme theme.
bug:6177794
bug:5728294
Change-Id: Id8c0b3549174b9599f971d6e3086ca427cfbaa39
DisplayList properties are still disabled default (flags in View.java
and DisplayListRenderer.h). When they are enabled, and when a View has
a DisplayList, invalidations due to property changes are now optimized
to avoid causing DisplayList recreation. This eliminates the drawing step
of invalidation (due to changes in these properties), only requiring
issuing the previously-created DisplayList to the GL renderer. Invalidation
is slightly faster (less overhead as we walk up the hierarchy), getDisplayList()
is potentially much faster (going down to ~0ms), depending on the complexity
of the View being redrawn and the size of the invalidated hierarchy.
Change-Id: I57587d5b810c3595bdd72a6c52349c2a3d1bdf25
A recent change to enable View properties at the native DisplayList level
mistakenly cuased Animation transforms get be ignored for any View with
a DisplayList. The correct code should have checked whether DL properties
were enabled for the view (disabled by default for now).
Issue #6173975 Animations are gone
Change-Id: I5d5f53f854fb1b533a3150158e84392d7283d2a8
Basic functionality of handling View properties (transforms,
left/right/top/bottom, and alpha) at the native DisplayList level.
This logic is disabled for now (via compile-time flags in View.java and
DisplayListRenderer.h) as we continue work on it (there is no advantage
to the new approach until we optimize invalidation and rendering paths
to use the new code path).
Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
Fixes a bug in View.removeCallbacks and View.unscheduleDrawable
where it was possible for the caller to remove all animation
callbacks if it happened to specify an action or who parameter
of null.
Also refactored the callback queueing code in Choreographer
to make it more intent revealing although the behavior remains
the same.
Bug: 6144688
Change-Id: Iba29dcda6b3aaad73af664bb63feab65ae3483e5
1. The need for sending an accessibility event to announce a context change
which does not cleanly fit into the existing UI transition UI events has
come quite a few time in application development. To avoid retrofitting
accessibility event types that do not semantically match the intent to
just announce a short message this patch is adding specialized event type.
Also a helper method on View is added to sheild developers from knowing
how to construct and send such an event.
bug:5977979
Change-Id: Iaf5f620426f8616be67fbf243a02ad5b606c949b
Bug #6120957
Using this new callback, views can interrupt and resume their
animations or other periodic tasks based on the current state
of the display.
Change-Id: I398f4abd421e9c5f207107bf1009a7b92cf45daa
