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
- DVB and ISDB ratings are added.
- Remove rating systems whose countries uses DVB and ISDB.
- Updated java doc for AR, AU, and BR.
Bug: 17494772
Change-Id: Ia2a63c7914148b42078decb8de1ae45baefb010d
Bug: 17675571
- Check for JPEG footer in correct location from ImageReader
when using the RGBA override.
- Add additional error checks in produceFrame method.
- Avoid allocating extra space for jpeg buffers due to
incorrect width calculations.
Change-Id: I926f37e8b3e5c4bad24c16dcee48d52adb1706dd
This checks if the phone app is currently getting or in a call when a
media key event is sent and sends it to the phone session instead of the
foreground app if it is.
bug:17527302
Change-Id: Ie5d6cf0c897da81d106f2b1a0561b79f4fc35e82
* commit '86d778155f077d5af10f43d0eb7b04584559e793':
Check the return value of bindService, and notify media browser client onConnectionFailed if it returns false.
A behavior change in the BT stack caused it to stop sending connection
changes for connected devices when you turn BT off. To work around this
we need to remove the connected BT route when BT is turned off.
bug:17512270
Change-Id: I3e5aa8863409c5abac51aa4e93a15f1978cf74b3
Handle the other ways queueBuffer can fail. Revalidate the buffers
properly, e.g. without clearing them.
Bug: 17630446
Change-Id: I22e0e89c2835eb6a461046a8cf3be03635088302
When the binder had disconnected we were setting the state to suspended
and then not setting it back to connecting when we reconnected. This sets
the state correctly when we are trying to connect again.
bug:17593681
Change-Id: I3fe95fa23ba43ac2dc3692fd28309b2f8e5a3599
For legacy behavior (using getInputBuffers) input buffer needs to
be made valid if queue fails. Otherwise, it becomes unusable,
and the buffer still belongs to the user.
In the new model, buffers obtained by getIn/OutputBuffer will
become invalid even if queue/release fails.
We do not do the same logic for output buffers, as these should
not be accessed even if releaseBuffer fails (which really should not
happen anyway unless codec is in bad state).
Bug: 17630446
Change-Id: Ica72a168d8aea97a0ee3f3ef49c60d0ca5a9fa06
Bug: 17379185
- WAR for SW Write usage flags being unavailable on
certain devices for JPEG (blob) format buffers.
Change-Id: Ic7299785b743f35dd47264b9d1cea01a88b71d91