Refactors density handling to look more similar to GradientDrawable's
implementation, which should make things easier to maintain. We no
longer update density directly in updateStateFromTypedArray, instead
handling it in applyTheme() and inflate().
Lazily calculates local density-dependent dimensions and invalidates
when the constant state density changes, which should ensure a random
call to applyTheme() will still result in the correct intrinsic
dimensions.
Change-Id: I726878a6cd75d38a550637e3e7a7b6bc68bcaf6d
Introduced PathData in Java, which is effectively a thin layer around the
native instance. PathData holds the verbs and points which is being used
in path morphing/interpolation. The verbs and points can be interpreted
into skia path commands, which is now done in native and therefore saves
a handful of JNI calls during path creation.
Removed the old PathDataNode mechanism and changed the PathEvaluator
to use PathData instead.
Also added tests and a microbench. Also ran CTS tests for VectorDrawable
and AnimatedVectorDrawable, and passed all of the existing tests.
Change-Id: Ia166f5172ff031fe18b154327967f911a62caec1
Previously we were discarding the Resources when forwarding from the
two-arg factory method to the one-arg method. This CL also updates the
documentation for ConstantState to be slightly more comprehensive.
Bug: 25688078
Change-Id: I4fbbf43f95fe792fa6f0bf9db8fd9a7cbfa51d1d
Also updates documentation for getIntrinsicWidth/Height to accurately
reflect the behavior of the existing implementations and provide an
explanation of what "intrinsic" means.
Bug: 25646242
Change-Id: I11daf57e598148adfda922cfc1ba31ed48a16bd7
Fixes a regression where the foreground was created against the density
in DPI rather than as a scale factor.
Bug: 25602850
Change-Id: Ia871aa5def4319682a73228efb599f31b65afdb6
Previously we would only mutate children when they were displayed, so
applyTheme() calls would be applied to the shared constant state. Now
we mutate() immediately after obtaining the child, which ensures we
have a clean constant state. This also allows us to remove extra
mutate() calls, since we know all child drawables are already mutated.
Bug: 25081461
Change-Id: I52390db268690a8e181f5b9bbe612b7ed6ce9359
All of the functionality of ConstantStateFuture has been moved into
prepareDrawable. We don't need the extra wrapper class.
Change-Id: I452b13320a838a23c8ec0dd486a89bf383142d7b
If a child drawable has no intrinsic width or height, don't attempt to
apply padding and insets to the child during the parent layer drawable's
intrinsic width and height calculations.
Bug: 25461370
Change-Id: Idf616bde0449231f38156da53feb858e1ae41c47
Avoid NPE if mutate() is called on a LayerDrawable with a child that
doesn't support constant state.
Bug: 25438651
Change-Id: I6bf5a90484fda44a7b5fd10ce7b798eaa799b68e
Refactors density resolution and offset/size scaling into static
helper methods.
Also fixes VectorDrawbale insets to be treated as offset-type pixels
rather than size-type.
Bug: 25081461
Change-Id: I10fcb9ebb6c67f853a27ca0ee008c31af4b85da0
Includes a refactoring of DrawableWrapper classes so that the wrapper
super class handles both drawable management and inflation. This allows
us to immediately call through to super() in inflate and applyTheme,
which simplifies density management.
Bug: 25081461
Change-Id: I8c157d340fd1f28a3a2b786c56850a67cdd452e4
We need to be more precise when removing the window that is being
replaced. We used to depend on the fact that we can remove it after
the first draw of the new added window. However, due to resizing the
old window might reset its draw state and that will trigger a removal
of that window.
We need to add an information about the window that is replacing the
old one and only when this new window draws itself, we remove the old
one.
This improves the transition after maximizing docked window. This is
a situation where first resize operation finishes and immediately
after we have a replacement operation.
Bug: 24914011
Change-Id: Ia8e5bb7872787e663ba23f26588f9c4db1a5e574
Also, compute LocaleList's string representation at construction.
This is to further push the cost of doing costly operations related
to LocaleLists to construction time.
Change-Id: Ia55b8ce66b1088ff54cb42eb1e11149b5bd10f17
Ensures that density scaling is applied to default dimension values
where needed. Previously, scaling was only applied when a drawable
was loaded from cached constant state; however, drawables that were
preloaded against a different density and first loaded in some other
density were not scaled.
Bug: 25081461
Change-Id: I0f8058cc01e2fe8d6bd7e255eba40485f3cbe48b
Only store stateful CSLs; otherwise, just use the default (e.g. the
only available) color.
Bug: 25074102
Change-Id: I050c89841d4c6bf22473a66c713a845b0358dc94
We never use this field as a rectangle, we only depend on its left-top
corner. Using a frame is only confusing about the purpose of this field.
Change-Id: I5d6e6321db4fa3203bb7e0f1975ae6ddd1ec09bb
Removes unnecessary invalidateSelf() from VD.onStateChange(). This is
handled by the view hosting the drawable.
Bug: 22984152
Change-Id: Idf11a0ffef392cb1d8452aa3f5f836b35027a756
Many classes in graphics/java and elsewhere deallocate native memory
in a finalizer on the assumption that instance methods can no longer
be called once the finalizer has been called. This is incorrect if
the object can be used, possibly indirectly, from another finalizer,
possibly one in the application.
This is the initial installment of a patch to cause such post-finalization
uses to at least see a null pointer rather than causing memory corruption
by accessing deallocated native memory. This should make it possible to
identify and fix such finalization ordering issues.
There are more graphics classes that need this treatment, and probably
many more in other subsystems.
This solution is < 100% effective if finalizers can be invoked
concurrently. We currently promise that they aren't.
(In my opinion, the real cause here is a language spec bug. But that ship
has sailed.)
Bug: 18178237
Change-Id: I844cf1e0fbb190407389c4f8e8f072752cca6198
When a GradientDrawable is loaded from scratch, initializeWithState()
is called with mColors == null. This sets mFillPaint's color to
0x00000000 -- transparent. mColors is then properly set in inflate(),
but mFillPaint is not updated there. It will be updated eventually
through a mutate() or ensureValidRect() call, but that's sometimes too
late.
In our case, a wrapping StateListDrawable called getOpacity(), and
since it caches the result, it never got updated.
This doesn't cause any problems on preloaded GradientDrawables, since
the new GradientDrawable created when fetching a preload will call
initializeWithState() in its constructor, fixing the GradientState.
Change-Id: Ic8caa7c6a7c1d4dae5ff31ae943831bd2e014f79
