The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.
That said...
Math is faster than FloatMath with AOT compilation.
While making the change, occurances of:
{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))
have been replaced with:
{(float)} Math.hypot(x, y)
Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:
Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().
hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.
Different implementations measured on hammerhead / L:
AOT compiled:
[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials
[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials
[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials
[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials
[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials
[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials
Interpreter:
benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
Bug: 16031597
This change also removes some unnecessary code from ScriptC construction.
Change-Id: I6680109deb34de841dfade769d556f5060aee423
(cherry picked from commit 8277a692be3c89519e368159e7707c8d35b89475)
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Cherry-pick from master.
Change-Id: I2d6081dd62f50f7d493045150b327ed120de7abd
Demo mode is protected behind a system setting. To enable:
$ adb shell settings put global sysui_demo_allowed 1
Change-Id: I2248e27a253bf9eac176e8be9153a2b147cefa40
Extend wifi display connection timeout.
Show a notification while connecting to wifi display.
Ensure that remote display providers are really trusted before
connecting to them.
Bug: 11257292
Change-Id: Iad0caaa30d7946df818bc75ade071f2e377f8a53
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Hide disabled routes from the chooser.
Fix layout of chooser dialog when the settings button is visible and
the list is very long to prevent truncation of the settings button.
Fix an issue when we fake the route connecting status when a route
is selected. The route changed notification needs to be propagated
to apps. Fake it better.
Immediately disconnect from a route when the connection is lost or
a connection attempt fails. Added a few new test displays for this
case.
Bug: 11257292
Change-Id: I360ab5dc937ad60d97592eab54b19f034519645e
This change adds a new media router service whose purpose is to track
global state information associated with media routes. This service
publishes routes to the media router instance in application processes
and handles requested state changes such as selecting or unselecting
global routes. The service also binds to remote display provider
services which can offer new remote display routes to the system.
Includes a test application for manually verifying certain aspects
of the operation of the media router service.
The remote display provider interface is essentially a stripped down
media route provider interface as defined in the support library
media router implementation. For now, it is designed to be used only
by first parties to publish remote display routes to the system so
it is not exposed as public API in the SDK. In the future, the remote
display provider interface will most likely be deprecated and replaced
with a more featureful media route provider interface for third
party integration, similar to what is in the support library today.
Further patch sets integrate these new capabilities into the System UI
and Settings for connecting remote displays.
Bug: 11257292
Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
This test depends on internals of the old WebView to work which have
already been removed. It doesn't appear to be testing anything useful.
Bug: 10427705
Change-Id: I5e93b212c33f22776050b6e1ec639e23f41a1d4a
Previously, a Fade transition would only affect a view if its
parent hierarchy was not also affected between the start/end states.
This caused problems for views which were removed from their parents
between scenes when their parents' visibility also changed between those
scenes. The effect would be that the transition would fade the parent...
but the child would no longer be in that parent, so the user would just see the
child view blink out.
This fix ensure that views are faded appropriately by fading them
regardless the parent hierarchy; if a view is removed from its
parent, fade it out.
Additionally, if that view has not been removed from its parent, but
its parent is no longer parented *and* scene being
transitioned from is based on a layout resource file (and thus
the views are considered temporary after transitioning), then it is
removed from its parent to be faded out in the overlay.
Also, renamed TextChange to ChangeText to be more consistent with
other transition class names.
Change-Id: I4e0e7dfc9e9d95c7a4ca586534b6d204c4f3bae0
It would be useful for a transition to declare not just which
targets it wants to be run on, but also which targets it wants
to avoid. For example, you may not want to animate the items of
a ListView, or some other specific target in the view hierarchy.
This change adds various exclude*() methods which make it
possible to alter a transition to automatically ignore specific
views, ids, or classes in the hierarchy.
Issue #10692794 Transitions: Need API for excluding targets
Change-Id: If38025cdbee537a545e5a4268cbbd763af4622c5
Issue #10460684 KLP API Review: android.view.transition and android.animation
Issue #10570740 Transitions: inflate transition targets from xml
Change-Id: I7a3f6d3aece2fcafc5efd555d033f79e86635c98
Bug: 10427705
These tested internals of WebViewClassic and will no longer build when
that is removed
Change-Id: I42af538dcb0343e9eff0b3fa85d7ff39f19c7c61
Refactor the new private virtual display API to also support
creating public virtual displays with various characteristics.
This feature requires special permissions and is only intended
for use by the system.
Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
Path ops can be used to combine two paths instances in a single path
object. The following operations can be used:
- Difference
- Reverse difference
- Union
- XOR
- Intersection
To use the API:
Path p1 = createCircle();
Path p2 = createRect();
Path result = new Path();
result.op(p1, p2, Path.Op.DIFFERENCE);
This code will subtract the rectangle from the circle and generate
the resulting path in "result."
Change-Id: Ic25244665b6691a7df0b0002a09da73d937b553b
Fix breakages steaming from recent changes:
- onGetLanguage is no longer called anywhere (it's used in API <= 17),
tests for it no longer apply.
- onLoadLanguage is called as item on synthesis thread queue. To return
value to client asap, onIsLanguageAvailable is called as well - added
missing expectations for mocks.
Change-Id: I205bc406f085e2c2f7e98f8495ddb96ad3701b97
Some view changes require more flexible transitions than the
defaults provided by Crossfade and TextChange - this change supplies some
of that flexibility.
Also, starting a new transition on a hierarchy undergoing a transition
caused the first to get canceled, then the start values to be retrieved.
The new transition should actually get the start values from the intermediate
state of the views, so we now cancel the previous transition only after the
start values have been captured.
Issue #9756349 Transitions: Crossfade does not handle interruption/reverse correctly
Issue #9295863 Transitions: Add behavior API/flags to various transitions
Issue #9275859 Transitions: Improve mechanism for transition interruption
Change-Id: I5a8c5a12466ddcab9e84e4880930563fa1216f3b
TransitionGroup.setDuration() was not propagating the new duration to
future child transitions correctly.
Also, Fade should restore a fully-opaque value when a transition ends, to prevent
the problem of mid-stream canceled transitions causing vie3ws to get stuck with partially
faded-in alpha values.
Issue #9755995 Transitions: TransitionGroup.setDuration() not handled correctly
Issue #9756655 Transitions: handle fading cancelation better
Change-Id: Id44569c6f4152a26ee382d04c30a2f035a1ebcf3
Transitions used to be three phase:
- captureValues(): get all relevant property values in the
affected view targets
- setup(): set appropriate start values for affected views
prior to any transitions being played
- play(): create/play Animators for affected views
Now the second and third phases have been collapsed (and named
"play()"). This single step sets initial values for target views
and creates any Animators that should be played during the transition.
The transition mechanism stores these Animators and then starts
them at the appropriate time in the overall transition.
Issue #9507585 Transitions: Simplify Transition.play() design
Change-Id: I3fc67599b38fe49eee885dc5d32444db90b7703b
Previously, Fade transitions did not work correctly on hirearchies; they
only handled individual views. in particular, they would side-effect all
fading views by removing them from their parent to fade them out in the
overlay of the scene root. This worked for the fade-out transition itself,
but caused problems when those same hierarchies were added back in and
another Fade was run on the hierarchy, because now all of the views inside
that parent node had been removed, so they didn't fade in at all.
The fix was to add logic in Visibility to detect when a disappearing
view was inside a hierarchy that was also disappearing, and to skip the
fade on the views inside that hierarchy, leaving only the top-most
disappearing view to be faded out, thus preserving the hierarchy under
that faded-out group.
Along the way, there were various cleanups, fixes, and refactorings in the
transition code, and slight API modifications.
Issue #9406371 Transitions: Removing view hierarchy not working correctly
Issue #9470255 Transitions: Separate different transitions by Scene Root
Change-Id: I42e80dac6097fee740f651dcc0535f2c57c11ebb
There are two applications: a source and a sink.
They should be installed on two separate Android devices.
Then connect the source device to the sink device using
a USB OTG cable.
Bug: 9192512
Change-Id: I99b552026684abbfd69cb13ab324e72fa16c36ab
Also a few little tweaks to the ArrayMap implementation. Note that
these are fairly parallel implementations; I looked at what I could
abstract out as a base class, but there isn't really all that much without
making the resulting code more general and thus slower. If we kept
the data structure for ArraySet the same as map, where the array has
two values per entry, then they could probably share a lot of code.
I couldn't really bring myself to do that at this point, though...
Change-Id: I9e0dd8baa8e1febcc1033ecef61623ad59ce4aae
Add TransitionManager.beginDelayedTransition() to handle starting a transition
on the next frame for a given scene root based on all changes that
take place between the first call to that method and the next animation frame.
Issue #9321937 Transitions: consider batching up multiple scene actions
Change-Id: I3fc92b6b4ec5ff42b1e678bcfd385703e32eba2a
Added equals() and hashCode() to ArrayMap to allow equals() tests
of maps with the same key/value pairs to return true.
Changed putAll() to handle the case of an empty map faster, just copying
the arrays instead of adding elements one by one.
Added to ArrayMapTests to test new equals() and copy constructor
functionality.
Issue #9299310 Optimize ArrayMap copy constructor
Change-Id: I1186a0eddd1fd53a0f380c2f3972fc1942cdf879
Small fixes in CrossFade to handle more general situations.
Also, added API to CrossFade to enable different behaviors during
the transition.
Change-Id: I12d17ab8f8f96be370c070373112ad8a62df9115
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
