Cloning drawables (which happens a lot) was creating copies of NinePatch
objects, which would cause the hardware renderer to generate more meshes
than necessary. Also avoid keeping a String we don't need (it was interned
but still.) Last but not least, remove 1 RectF per NinePatch in the system.
Change-Id: If4dbfa0c30892c9b00d68875e334fd5c2bde8b94
The three arrays were being reconstructed and copied for each add
and each remove. By replacing them with ArrayList only three
constructions total are required. Also, the number of
System.arraycopy() calls is halved.
Change-Id: I0f8def1b517eb1bc5f930fcd5d3d1e0394071f0e
Conflicts:
core/java/android/view/WindowManagerGlobal.java
Small fixes in CrossFade to handle more general situations.
Also, added API to CrossFade to enable different behaviors during
the transition.
Change-Id: I12d17ab8f8f96be370c070373112ad8a62df9115
When relaunching activities the window manager clears out all windows
by calling a ViewRootImpl.die() in a deferred fashion. Then it
immediately deletes the ViewRootImpl and its view from its list
of windows. When the die() is eventually executed it calls
dispatchDetachedFromWindow() which tries to remove the previously
removed windows causing an Exception to be thrown.
This change waits to remove the windows until after die() has been
completed. Fixes bug 8253030.
Change-Id: I5b41be1c6b776e32128c064267653db98bd95292
When a View is added to a ViewGroupOverlay, it must not be parented
in another container. If it is, it will automatically be removed.
This works in general, but if there is a LayoutTransition on the
view's parent, then the actual removal will be delayed until the
transition completes. This means that the call to add(view) in
the ViewGroupOverlay's container will fail and throw an exception because
the view is still parented for the duration of the LayoutTransition.
This fix cancels the running transition to ensure that the view is not
parented prior to adding it to the overlay's container.
Issue #9303245 Crash combo: add(View) and animateLayoutChanges
Change-Id: Id4eaddccf64c353fc77e020882b978cdeb14c0ef
Added new field (+setter and getter) to SynthesisRequest with
Uid of a calling process. TTS service will be able to discover
packages names associated with caller using
PackageManager.getPackagesForUid.
This will allow to block buggy or poorly designed programs from
an unintentional DDoS attacks against TTS service.
Bug: 8625440
Change-Id: I5ac0ea191f952495c00301f17efdf28205353ae4
The logic that canceled underlying animations caused a problem
when there were more than one animation in the list (due to removing
items from a list that was currently being processed elsewhere).
Change-Id: Ie207f340b5d7de4ffcf56a26c05ec394abb80224
The new ArrayMap class is more efficient for small collections.
Transitions use maps all over the place to collect/use property
values in setting up the transition animations. Changing to ArrayMap
should be more efficient, especially in terms of memory allocations
and GCs.
Issue #9276256 Transitions: Reduce memory allocations
Change-Id: I07b7d4ba68d5a207808eca11943aa3578fa90e3e
Previously, ValueAnimator would always call into the Trace class to
log start/end events. When the animator is an ObjectAnimator, this
call necessitated building a new String to capture the animated property
name. This fix puts the calls to Trace inside a check for isTagEnabled(),
to ensure that we only bother building the trace name when tracing is
actually enabled.
Change-Id: I56ef093f3b67b31a19c861f9d1e44a84341edf53
The behavior of running a transition is janky and unpredictable,
when there is already a transition running on the same scene root.
Usually, the new transition simply jumps to the end values, or
jumps to the start values for that transition and animates from
there.
A better approach is to cancel any running transition first, the
start the new transition from that point.
Even better would be to blend old/new transitions, or at least adjust
the animation timing according to where/when the previous transition
stopped. In the meantime, this fix is at least better than the
previous approach of ignoring running transitions.
Change-Id: I4f5fabb55f6454f1e9d66589a9a7c36f9fc013fb
Moves the call to onScrollChanged from onTouchEvent into onOverScrolled,
which ensures only one of scrollTo or onScrollChanged will be called in
a single execution.
Bug: 7584549
Change-Id: Ibccd98a30835efad75eb41bcdd4b136e1b8e0ddd
Treats headers and footers as "enabled" list items when header and footer
dividers are turned on. Also fixes incorrect drawing of dividers when
"stack from bottom" is enabled.
Bug: 7288159
Change-Id: Ibfc48841502a410357db04aaed01072703c7d36c
setDuration() wasn't handled correctly for TransitionGroup; it should
propagate the value to its children.
Also, videos with no ids were not being handled correctly. The transition code was
using the default id on those views (-1) to store start/end data about the view,
causing multiple non-id views to clobber values in the hashmaps. The correct approach
should be to ignore default id values - only store information about the view
instances, not about the unset ids.
Also, added a new test InterruptTest to be used to fix the current behavior of
not handling situations where new transitions start while old ones are still taking place.
Change-Id: I4e880bdbb33cc26d487bceb0d56e463e72f7621f
This change also fixes a race condition. If multiple UI threads are used
in a single process, RelativeLayouts could end up using the same nodes
in different windows, causing mayhem and headaches.
Change-Id: I9ba4a0bf05d44e1a1e7a82443d40c500c657cd7a
