History log of /frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
fa794eb0025dbec6c1b90135495081d42f06bdaf 15-Jun-2015 Diego Perez <diegoperez@google.com> am 2f710356: am 13c06d6c: am 1f33bdad: am 5e50e00c: Merge "Fix for shadows on theme editor" into lmp-mr1-dev

* commit '2f7103565cf1732d6d1281195cfa49a1564751d7':
Fix for shadows on theme editor
e5be1d7a397db08a4dd75c66bdbbc6e2b61baaa8 02-Jun-2015 Diego Perez <diegoperez@google.com> Fix for shadows on theme editor

If the preferred ColorModel doesn't support alpha, the shadows are
incorrectly rendered. In the theme editor on Linux, the graphics device
object doesn't support alpha so we need to use a different color model.
We default to ARGB which works fine.

Change-Id: I3e71e3d086fa4975a9149d36792e574813f37dfd
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
52ef7fce1626868d6be34f4038cd852259ad6a26 07-May-2015 Diego Perez <diegoperez@google.com> am ffeb8117: am 9c13c8de: am bc47abe4: Merge "Make sure shaders use a color model compatible with the destination." into lmp-mr1-dev

* commit 'ffeb8117b139f61dd7c92bda6a7d47b83871cb66':
Make sure shaders use a color model compatible with the destination.
2d3449f982f9f4b9f4370142bb846d2dbab5a38e 12-Mar-2015 Diego Perez <diegoperez@google.com> Make sure shaders use a color model compatible with the destination.

Change-Id: Iaf6e14bb86835c36a5b0c37519ac2ee794d10081
(cherry picked from commit 158ac454073a460375123d7d05152a7c6490efb6)
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
c2a0b4482d7144e8382346ea4c22c7b89368fec0 02-Oct-2014 Neil Fuller <nfuller@google.com> resolved conflicts for merge of ee665151 to lmp-mr1-dev-plus-aosp

Change-Id: I2588c65b7a9fa43f968151a206924a804f0595a7
33253a4baa6279f81a73425b49dfb6abe5f5416e 01-Oct-2014 Neil Fuller <nfuller@google.com> Switch from FloatMath -> Math and Math.hypot where possible

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
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
79ee46172b45b0652b2bf8dc8b8889da51ff2459 29-May-2014 Deepanshu Gupta <deepanshu@google.com> Update delegates

Update layoutlib delegates in response to commit
a631a36de986acea2ef6fdfbaf3441a28b914b15

Change-Id: I897a7e3a61286bfae9054415d555febe16410106
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
84151432e7ead6666eb8cf6377bff577b2027694 27-Jan-2014 Narayan Kamath <narayan@google.com> Track 64bit changes to android/graphics.

All pointers are now 64bits wide, so should be
represented as java longs and not ints.

Also changed DelegateManager and SparseWeakArray to
reflect the new world order.

(cherry picked from commit 88a8364c386c694f7ad56662ef89713dbf7c9d63)

Change-Id: Ic2f55dd6235751169c5014f9d2ccf3f544259a87
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
88a8364c386c694f7ad56662ef89713dbf7c9d63 27-Jan-2014 Narayan Kamath <narayan@google.com> Track 64bit changes to android/graphics.

All pointers are now 64bits wide, so should be
represented as java longs and not ints.

Also changed DelegateManager and SparseWeakArray to
reflect the new world order.

Change-Id: Ic32b6b53818dbae9b949f03004c4fb6dae26cdbe
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
282e181b58cf72b6ca770dc7ca5f91f135444502 24-Jan-2014 Adam Lesinski <adamlesinski@google.com> Revert "Move frameworks/base/tools/ to frameworks/tools/"

This reverts commit 9f6a119c8aa276432ece4fe2118bd8a3c9b1067e.
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
9f6a119c8aa276432ece4fe2118bd8a3c9b1067e 28-Aug-2013 Mike Lockwood <lockwood@google.com> Move frameworks/base/tools/ to frameworks/tools/

Change-Id: I3ffafdab27cc4aca256c3a5806b630795b75d5c8
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
46d43ccfd8cef75b4315828073c094cf1efb05ff 03-Feb-2012 Xavier Ducrohet <xav@android.com> Make Layoutlib compile on Java 6.

Change-Id: Ic8f0e321c6c218de83664fc01f253a07fa80852c
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
cc4977d0fdaf657907912fd6cc2f9426dc8d2e36 22-Feb-2011 Xavier Ducrohet <xav@android.com> LayoutLib: Hold onto delegate references.

When an object is given a delegate to hold onto, keep
the reference to the delegate instead of its native integer.

Also change the way the finalizer works by not explicitely deleting
the delegate. Instead we want the delegate to be deleted when
nothing holds a reference to it. To do this, instead of using
a regular SparseArray, we use a SparseArray of WeakReferences.
Because the main Java object that "owns" the delegate does not
actually holds a reference to the delegate, we fake this by
having the delegate manager hold a reference to delegates for
the main object. This is added/removed as the object is created
and the native finalized is called.

This makes layoutlib behave more like the JNI code where the native
objects are reference counted, and where the Java object can be
deleted but the delegate it owns is kept around (usually because
another type of delegates hold a reference on it.)

To properly handle the WeakReferences, we need to be able to
regularly clear the SparseArray of WeakReference that were
referencing objects that have been GC'ed.
Since the SparseArray is regularly being compacted (actually only
when items are removed), we use a custom SparseWeakArray (started
as a straight copy of SparseArray) that handles the WeakReference
and takes care of compacting the array by removing deleted indices
and WeakReference that returns null. Since our specific use case
doesn't call actually delete() or remove(), the compacting
only happens when the array needs to be resized.

Change-Id: Iacc5c1ff5b21732b8816fda87eb090da12d034e0
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
9a4fe29c8d92014d2d9a848e9116b8cc9d0842f9 10-Feb-2011 Xavier Ducrohet <xav@android.com> LayoutLib: Annotate the custom delegate methods.

Every method implementing a delegate needed by the
layoutlib_create bytecode modification must now be
annotated with LayoutlibDelegate.

The methods in the original source code that are delegated
are already automatically annotated. Now with the implementations
being annotated we can do bi-directional tests and find not
only missing implementations but also dead obsolete code.

This will be useful when backporting to earlier versions of
Android, or when native (non public) method disappear. In fact,
the new test detected one such method in Shader.

Change-Id: I491708b68ac2736ca5669aa86cd5e930a00f9db3
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
51a7e5447de94791c464cda5cc6ebbf616d73c80 15-Jan-2011 Xavier Ducrohet <xav@android.com> LayoutLib: update logs to use new data bundle

Also change some resource.resolve tags to resource.format

Change-Id: I3f0b0d2eb69a5ec98375e4014a3bb1bfceb8c855
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
918aaa5717fce6081557c82ce1c439b6922737d5 13-Jan-2011 Xavier Ducrohet <xav@android.com> LayoutLib: Use the new log tag constants from LayoutLog

Change-Id: I29dd578ae16405358d3673caf13528be393f0967
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
56222cfbe9973c518f7e8c9113c614de80b5a4b2 13-Jan-2011 Xavier Ducrohet <xav@android.com> LayoutLib: use tags in logs.

Change-Id: Ib85272249d285ecef409bf063903bcd91514a424
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
d348b6eaa98e23cb38d90906df109aaa2d20ea7f 20-Dec-2010 Xavier Ducrohet <xav@android.com> LayoutLib: support for Path and BitmapShader using delegates.

Also created delegates for all missing shader, xfermode
and patheffect classes. Moved the logic of the xfermode,
and patheffects that was in Canvas_Delegate into the
xfermode/patheffect classes, and added support (in all
3 clases) for knowing if the shader/xfermode/patheffect
is actually supported or not. Make use of fidelityWarning
in LayoutLog if they are not.
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
d9c64369cf9be6568af2d79c35fb470cc261730d 14-Dec-2010 Xavier Ducrohet <xav@android.com> LayoutLib: Fix gradient rendering.

- fully support canvas transform
- fully support shader local transform
- fix repeat/mirror issue in the negative values.

Change-Id: Ib2aa7ade1c2702da4364cbda9a5a3ae72c1d3174
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
c2e9651bf386a1f7bf7fc706cf5424950570470c 10-Nov-2010 Xavier Ducrohet <xav@android.com> Layoutlib: New bridge implementation using the new API 5.

Since the new API prepare for stateful layoutlib, major
reorganization of the code.

New "android" sub-package for all extended android classes.
Also moved BridgeInflater in here so that all extended classes
are in this package. Only delegates and classes replacing
renamed classes are in their original android.* packages.
Also created full file for the empty implementations of
IWindow and IWindowSession.
New "impl" for the dirty work implementation.
Main package contains the basic implementation of the API.

Most of the code that was in Bridge is now in .impl.LayoutSceneImpl,
with the main init/inflate/render code split into the contrustrutor,
inflate() and render().

Change-Id: Ie15b15e5a1b2388cd6ef82e518345b1fc02ec981
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java
251d2e99245095369b52d891a660b2ed270f02e0 02-Nov-2010 Xavier Ducrohet <xav@android.com> Layoutlib native delegate: primitive shapes and shaders

Change-Id: Id2b0c6231589e82d8e96c9f019042eba348a6583
/frameworks/base/tools/layoutlib/bridge/src/android/graphics/RadialGradient_Delegate.java