libcore now offers a wider variety of 12-/24-hour time formats,
so be more specific about which one we want here.
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
All supported locales use only U+2025 and U+2026 to represent
ellipses, and it will unlikely change in future. Given translated
resources are inconsistent and often use three dots it is safer
to use constants instead of resources.
Change-Id: I51a6cb903f62f739fbadd6b78e5765c0028d641a
With a hardware keyboard, using up arrow within the top line should
move to the beginning of the buffer, to better match desktop text
editing expectations, and similarly for down arrow on the last line.
This patch implements that behavior.
Bug: 17385784
Change-Id: Ia23c23c9cc2462558bca9aaffec7d83e284d55e8
We weren't getting correct results from Layout.isRtlCharAt, because it
was only testing half of the correct predicate for whether the argument
was inside the run. This patch restores the correct predicate.
Bug: 17381011
Change-Id: Ib0a77cc182f4ca4bfe824e85b7aff7268f465d73
This reverts commit 5287e37687f117ac0b690100ad90842eff58d15a.
Reverting because only worked if settings cache had been populated
already.
Bug: 17302505
Change-Id: I4360606e9d9c6409951f0a02bd0b78c55085e0c6
Remote views may be inflated in another user so
explicitly use processes user id rather than the
user id of the context.
Bug: 17302505
Change-Id: I985c91745f03dd7e6b2ab6357600077664d8e6be
The test fixes for bug 17262063 showed up a real issue for
non-English locales with the Time.format() method:
If the Android string resources that contain the pattern use
non-ASCII characters then a '?' would be output instead of
those characters.
For example, in France the pattern for '%c' includes a 'à'
(a with a grave accent) and Japan includes 日.
The problem was due to converting the pattern to bytes using
the US_ASCII character set, which turns non-ASCII characters
into '?'. The code has been changed to use char throughout
and avoid bytes.
Internal documentation has been improved.
Some calls to modifyAndAppend() have been replaced with a
direct call to outputBuilder.append() because the
modify step is guaranteed to a no-op for the literals given.
The formatter has been changed to use Locale.US because it
is only used for outputting numbers. It has been renamed
to make this more obvious and the locale field has been
removed.
Bug: 17262063
(cherry picked from commit 788cb18f65)
Change-Id: I96ee158fbeb01827f0bbf022631625416f872fdb
The test fixes for bug 17262063 showed up a real issue for
non-English locales with the Time.format() method:
If the Android string resources that contain the pattern use
non-ASCII characters then a '?' would be output instead of
those characters.
For example, in France the pattern for '%c' includes a 'à'
(a with a grave accent) and Japan includes 日.
The problem was due to converting the pattern to bytes using
the US_ASCII character set, which turns non-ASCII characters
into '?'. The code has been changed to use char throughout
and avoid bytes.
Internal documentation has been improved.
Some calls to modifyAndAppend() have been replaced with a
direct call to outputBuilder.append() because the
modify step is guaranteed to a no-op for the literals given.
The formatter has been changed to use Locale.US because it
is only used for outputting numbers. It has been renamed
to make this more obvious and the locale field has been
removed.
Bug: 17262063
Change-Id: I32b92f7f7e3e6931d3514d87f1d9a38f136d4021
We used the full width of a line, including trailing spaces, to compute
ellipsis, sometimes causing spurious ellipsization when the space pushed
it past the layout width. This patch uses only the width up to the last
graphing character.
Fix for bug 17186801 "First line of title text is getting truncated even
if there's space on second line"
Change-Id: I49d07c18c8dd1d3b279f591224d23e10645dc8c0
The main purpose for this change is to prepare for adding support for
alternative line breaking algorithms (such as optimal line breaking).
The existing implementation of line breaking was intertwined with
measurement, so it wasn't structured in a way such that other line
breaking algorithms could be easily added. In addition to this,
algorithms (such as optimal line breaking) are usually fairly complex
and computation-intensive, so it is advantageous to implement them in
native code.
This has several other advantages:
* Unlike the Java code in the previous version of generate(), this
implementation separates line breaking from measurement. This
makes it easier to understand and modify the line breaking process
without affecting measurement (and vice versa).
* This native implementation of greedy line breaking is identical to
the Java version in terms of functionality, and it is similar in
terms of performance, depending on the use case. The performance
gains from this change are not significant due to increased JNI
overhead. However, this change is a step in the right direction in
terms of increasing performance. Once more code moves to C++,
there will be fewer JNI crossings per layout call and less data
will be passed from Java to C++, resulting in better performance.
This change moves line breaking from Java to native C++ code. Inspired
by the "Breaking Paragraphs into Lines" paper by Knuth and Plass (1981),
we express the line breaking problem in terms of 'box', 'glue', and
'penalty' primitives, along with a few others. Our implementation
differs in a couple ways:
* We do not want to clip text when words are wider than the view, so
we add a new primitive type to represent break opportunities
between letters. These breaks are avoided whenever possible, but
when single words do not fit on lines by themselves, they can be
broken so the entire word is visible.
* We have to support tab characters, along with user*specified tab
stops, so we add a new primitive type for that purpose.
* We are left*aligning text, and so we are not using shrinking /
stretching glue.
* We do not support hypenation, so we do not use penalties that have
widths.
Change-Id: Ia22d1d1275ef26ff3d7b41ee2658e4db525a0305
This addresses b/16486549.
This change updates public documentation to specify the behavior of
LeadingMarginSpan2s. This change specifies what happens when a
LeadingMarginSpan2 is combined with other LeadingMarginSpans. This
behavior was not previously documented.
LeadingMarginSpan2s specify the number of lines used for the leading
margin. When laying out and rendering, for all LeadingMarginSpans, the
first line margin is applied for the number of lines specified by the
LeadingMarginSpan2.
Previously, this behavior was slightly buggy -- the LeadingMarginSpan2
affected all LeadingMarginSpans when laying out text, but not when
rendering.
This change is designed to cause the least amount of breakage in
existing code while achieving consistency with the way
LeadingMarginSpan2 is handled in layout and drawing.
For the most common use of LeadingMarginSpan2 -- getting a multi-line
first margin in the first paragraph of text in a layout -- this should
cause no change in behavior. For any other uses, the old (buggy)
implementation most likely did not exhibit correct behavior to begin
with, so developers were most likely not relying on that functionality.
Change-Id: I6f69df09c0130e703458e65bf3eaac4a905df56e
When processing text ending with a newline character, calling
MeasuredText#setPara() on the whole buffer is inefficient because the
call results in a copy of the entire buffer.
Change-Id: I6fa038d950f6287665bad3dc0070234c98bc8a7a
.. and use Locale.getScript() instead of ICU.getScript.
bug: 15876704
(cherry picked from commit 08b3516984)
Change-Id: Ifac179e0577d66062f32c95372b631bf574dfdf9
