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
Current implmntation only sends rotation updates on orientation
changes, so does not handle direct 0<->180 or 90<->270 transitions.
Update rotation based on an OrientationEventListener instead of
Intent.ACTION_CONFIGURATION_CHANGED
Bug 17606902
Change-Id: I01dfcd1c587f5b2e8a96365c2389782ad77936ef
Change parameter `nativeObject` from type `jint` to `jlong` to match its JNI
signature.
Bug: 12890910
(cherry picked from commit 3cb78498d3f664f541ba7d28f4543cf8c12733f1)
Reported-By: ashok.bhat@arm.com, marcus.oakland@arm.com
Change-Id: I624dfb41485be823d31797514664d3a5f9e52eb0
When there was no thumbnail for a given image, the getThumbNail() convenience
method could return a previously-returned thumbnail instead of null.
b/15771860
https://code.google.com/p/android/issues/detail?id=40714
Change-Id: Ibd18e048145bf347469f800afdf436247ea6b693
The jstring "stringValue" was not never freed.
In the case where "str" was NULL the whole cleanup part (see "goto out")
was even skipped.
This patch makes getObjectPropertyValue() behave like
getObjectPropertyList().
Change-Id: I5a7ec3611036f5253a054b00064999bcd1d1c29e
Synchronize modifications of volume index by VolumeStreamState
class mutex instead of using synchronized methods.
This avoids possible cross deadlock when modifying volume on
two stream types simultaneously and one is slave to the other.
Bug: 13730145.
Change-Id: I13406c71010ce0c2e2f08f660b6101f310396c98
Call release for DrmManagerClient to avoid resource leaks
Introduced by following commit (5d143ad4a8f...),
"Media scanner support for FL(Forward Lock) DRM file types"
Change-Id: Ic3c458579f4e99b3b072a2e13362d1996b982589
When the app's vm-heap is not enough, memory allocation for big
object like bitmap may failed.
This patch add protection for bitmap creating to avoid segment
fault error in the following GetIntField function.
Change-Id: I63977dc602f4ed395afd11004a0ed027173fb685
Signed-off-by: wang, biao <biao.wang@intel.com>
Signed-off-by: TingX Li <tingx.li@intel.com>
Signed-off-by: Wang LiangX <liangx.wang@intel.com>
This will avoid problems caused by automatic type
promotion of parameters when passed to a variadic function.
Change-Id: I9340cf4bc3afcb84ebb2843d2aaa1e832b0df7f4
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
setAvrcpAbsoluteVolume is passed wrong unit parameter from AudioManager.
It cause maximize volume in Bluetooth speaker/device.
The volume expected by Bluetooth Avrcp should be from 0 to 15.
But the current volume parameter passed to Bluetooth Avrcp is from 0 to 150.
It is scaled by 10 times than the correct volume.
index = rescaleIndex(index * 10, streamType, streamTypeAlias);
Should divide the volume by 10 before pass to Bluetooth Avrcp.
bug:12495379
Change-Id: I4160588e92ee384e21a75d63036d8bd6ccb30621
