libcore now offers a wider variety of 12-/24-hour time formats,
so be more specific about which one we want here.
(cherry-pick of 85f60d3a03b5b5d9a0e8b8a138eb85a6b53a1eca.)
Bug: 10361358
Change-Id: I846ab7a6f84cd49e876ad21e9366aff1600e0530
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
Setting LayoutParams on children triggers requestLayout
which can be expensive and result in significantly lower
framerate for children layouts that don't need it. When
requestLayout method is invoked the needToMeasure boolean
will be true, this is what we'd like to avoid unless
it is actually needed.
BUG: https://code.google.com/p/android/issues/detail?id=72733
Change-Id: Id5d8f3431b5f943b1279eae41ee43d32a99514fc
Signed-off-by: Jacob Abrams <satur9nine@gmail.com>
Client has to call recycle() on parcel object after its usage
otherwise native layer of binder won't clear the resources of
parcel which were allocated for IPC
Change-Id: Ib31ddcc92aa4ebd80bb66729922b9133692e9c9e
Changed marquee text to scroll according to
the reading direction. Arabic text will
show the right edge and scroll towards
the left edge and vice versa for Latin.
Corrected marquee flicker when scroll animation
finished. The ghost scroll's x position was cast
to int and it made the text flicker when
marquee stops.
Ghost part didn't display for RTL languages.
Added multiplication with
getParagraphDirection to negate the ghost
offset.
Change-Id: I689039118df01a62f73ef0079c857fea1bfcc5a0
Add check for invalid range before setting for further check
at end of parse() loop.
Bug:12936072
Change-Id: Ie0b33b8e69fe47e5d3371640be5681f13a4e4f6e
(cherry picked from commit ea4adf2847)
If a view does not have callbacks, or content description, or does not draw
content, and it is marked as important for accessibility auto, then the system
decides it is not important and does not report it. Apparently progress bar
draws content that means something and it should be important for accessibility
by default.
Change-Id: Icd3837fb8b9e208c98b90707f3b195622d71949e
(cherry picked from commit 7face75f2c)
* commit '57f8a4b4ed48ae3e2488bb3bafcd40137c71ec18':
Fix bug #12066726 java.lang.NullPointerException at android.widget.CalendarView.onScroll(CalendarView.java:1216) - DO NOT MERGE
* commit 'cb6dcd7af2d015b7a3d49f1224936241747bcb43':
Fix bug #12422326 Unable to change text direction programmatically using setTextDirection Android SDK API - DO NOT MERGE
* commit '1ff2df6194148f487ccb014a7c5302fa8ffe2571':
Fix bug #12066726 java.lang.NullPointerException at android.widget.CalendarView.onScroll(CalendarView.java:1216) - DO NOT MERGE
* commit '2b58a29f825e6442d8767a36adaf1770b86d5725':
Fix bug #12422326 Unable to change text direction programmatically using setTextDirection Android SDK API - DO NOT MERGE
- force TextView internal layout recreation when its TextDirection is changed
Change-Id: I7d6b088a9235362e03cb6694392df71bbf5a323a
(cherry picked from commit 22228fec05)
When the positions for the new step is calculated in
a Seekbar, a rounding error can appear.
This is fixed by round off before casting.
Change-Id: Ie2cf201ef670ccc2297e9bc4c7f415a826e44a41
