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
There are now some new trim memory levels that are sent to
non-background applications as RAM becomes low.
There is a new API for an application to retrieve information
about memory trimming and such on demand.
Fixed various checks against the memory trim level to be
robust (not compare against exact values).
Change-Id: Ifd1c6151124350168aef20a94e517166fd2e03eb
Creating the layer, if necessary, takes the bulk
of the time - just do the creation, and schedule a
deferred update
Change-Id: I21399ebd5d2929a4f242ec1c08e3f97fed1ef58a
This is especially useful for slow animations such as blinking the
cursor, which only needs to happen after a certain amount of time
has elapsed.
Change-Id: If1163a3480078c75d6461eb8f96d8bf8b625534f
When WindowManagerService's events are enabled/disabled, the state of the
display is dispatched to the known windows. This allows ViewRootImpl to
ignore draw requests until the screen is turned back on. This can potentially
lead to significant battery savings. For instance, a launcher widget showing
a repeating animation will cause the CPU and the GPU to wake up regularly
without this change.
(Change submitted by Intel and merged manually)
Change-Id: I7f93b0e60c3e6de1705f619e80860c36b1cdb978
