First, this CL removes the need to decompose the DrawFilters
in Java and instead passes the SkDrawFilter to HWUI directly.
This also allows the removal of duplicated logic between HWUI
and other Canvas implementations regarding Paint filter levels.
Second, the DrawFilter is now stored in the DisplayListRenderer
where we apply it to every paint BEFORE it is stored in the
DisplayList. This eliminates the need to filter all Paints on
playback and removes additional complexity at playback.
Finally, as a result of storing the filtered paint we can now
do a better job caching the paints. This takes advantage of
recent changes in Skia to quickly enable quick hashing and
comparison of paint objects.
Change-Id: Iec507a2d894827975cc4f1d22241542bb0534b4e
Since requesting the native pointer triggers specific paint behavior we need
to ensure that the field is private and that callers use the public method.
Change-Id: I598a8bf2904960023397728c1ce4502ce408348e
Removes all implementations of three-arg ConstantState constructor, since
we handle mutation and applyTheme() in Resources now. Moves progress bar
tinting to android:tint attribute. Correctly implements applyTheme() and
canApplyTheme() in all drawable wrapper and container classes.
Change-Id: Ic9cb43d0d6228aa4914f3124bed234b837beaa41
Projecting ripples places them under shadows, which is not
ideal. Punting this workaround and waiting until we have
proper support for rounded corner clipping on windows.
This reverts commit f90b6bd54f60960a790b5bd507a0d75d961a981a.
Change-Id: I61946649bbb1bf74a969d74e5353608afc8e4463
The Paint_Delegate changes from lmp-dev reference mNativePaint, which
has been made private in master. Change it to being package-protected
to fix the build.
Change-Id: I4bf30a530f0145cf7697cef6aa9a698fc9bab4ed
We already handle bounding rect in draw(), so this just ensures
that ripples are always clipped to window background outlines
until we can implement more general clipping.
BUG: 17498583
Change-Id: Iaff51fb177b017a11822bdf4f31c117fc9522c15
This ensures that drawables are completely separated from their cached
constant states before applying a theme. After this, we can remove the
implicit (and incomplete) mutation in the clone constructors.
Also implements missing mutate() method on ClipDrawable.
BUG: 17646144
Change-Id: If0d66b0a85724d76e0a4f506758c7ba3c0aa3410
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
We missed the alpha for the vector drawable root level in the documentation.
And the animation target can be vector drawable itself for the alpha value,
which is more than path and group object.
b/17696183
Change-Id: Ic9d441fbdf411dad92718ae5adbc6655fe708453
