| 2180ba7abd7edbd5b3a880d15f828b58ab34e578 |
|
02-Dec-2014 |
Chris Craik <ccraik@google.com> |
Sync ViewOverlay size init with RenderNode
bug:18381202
Setting mRight/mBottom must be accompanied by updating the RenderNode.
Change-Id: I4dae06a5ca43247b0b3642d85808e2724e486692
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| 49e6c73913e9bee58ea5e3984be151ee8e033163 |
|
31-Mar-2014 |
Chris Craik <ccraik@google.com> |
Move most TransformationInfo properties to RenderNode
This change dedupes the various properties that were represented both
in TransformationInfo, and RenderProperties on the native side.
RenderNode (and its associated properties) are now permanently
attached to a View in SW or HW. The native copy of these properties
are their sole representation.
Alpha to come in a later CL.
Also fixed issue with copying RenderNode's transform, and added
support of deleting RenderNodes in software rendering.
Change-Id: Ideb6e7f32b780e87aa1c32637c368356b3eee3a1
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| 39de9bfa7f922f1994c4a6dd4494c31042cf6bd3 |
|
11-Dec-2013 |
Alan Viverette <alanv@google.com> |
Verify drawables added to ViewOverlay so they can be scheduled
Change-Id: I73d0633966f84876e2093c874acd6813efdbc370
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| e4a2d7c48e17dd1c2f59dd18e91997029a6d0bdb |
|
22-Jun-2013 |
Chet Haase <chet@google.com> |
Fix ViewGroupOverlay's handling of invalidating viewgroups
Invalidating a view property (alpha, rotation, etc.) causes an
invalidation process that does not work correctly when the view is
in a ViewOverlay. Specifically, if the view is not directly in the
overlay, but is instead inside a hierarchy which is within the overlay,
then the invalidation process stops at the ViewOverlay itself, because
the ViewOverlay has no "parent" view.
The fix is to override the invalidateChildInParentFast() method, just
like we override invalidateChildInParent(), to forward the invalidation
to the host view.
Issue #9389230 Animations not running for nested views under ViewGroupOverlay
Change-Id: I03fcef10ed1c8a91cb26d5d9d6945634b0b695b5
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| ce08ce539a083b31cfffd3aa98173885f0e4a3d9 |
|
06-Jun-2013 |
Chet Haase <chet@google.com> |
Fix crash with LayoutTransition and ViewOverlay collision
When a View is added to a ViewGroupOverlay, it must not be parented
in another container. If it is, it will automatically be removed.
This works in general, but if there is a LayoutTransition on the
view's parent, then the actual removal will be delayed until the
transition completes. This means that the call to add(view) in
the ViewGroupOverlay's container will fail and throw an exception because
the view is still parented for the duration of the LayoutTransition.
This fix cancels the running transition to ensure that the view is not
parented prior to adding it to the overlay's container.
Issue #9303245 Crash combo: add(View) and animateLayoutChanges
Change-Id: Id4eaddccf64c353fc77e020882b978cdeb14c0ef
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| d8b0b233249c176b7adc1a7ee1e97f89e6a0698c |
|
20-May-2013 |
Chet Haase <chet@google.com> |
Add null check in ViewOverlay
View.getOverlay().clear() can failed with an NPE if there are
no drawables in the overlay. Fix: add a null check before dereferencing
the mDrawables field.
Issue #8895794 getOverlay.clear() crashes if drawables were not added previously
Change-Id: I9b2a63036450915681ba3a89a0911e2490063702
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| face742d31a7a72a4bdced5594e00e51ecee6c84 |
|
16-Apr-2013 |
Chet Haase <chet@google.com> |
Avoid repositioning unattached overlay views
Adding a view to an overlay usually entails removing the
view from its current parent, if it has one. ViewOverlay.add() will
do this automatically. At the same time, it will check to see whether
the parent view is in a different global location than the overlay's
host view, and will adjust the added view accordingly. This enables
the caller to simply toss a view into an overlay and have it end up
at the same global position on the screen.
the problem is that the current code doesn't bother to check whether
the old parent is attached. If that parent has been removed from the
view hierarchy before this overlay operation, then it will show up as
being at (0,0) in the window, not its old location. This results in the
view being mis-positioned in the overaly.
Fix is simple: if the view's old parent is not attached, simply remove
it from that parent before adding it to the overlay; don't try to compensate
for its position which is based on wrong information.
Issue #8620319 Overlay should only use relative window locations for onscreen parents
Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| edf6f4b49f6e77c349f5055372ce381b74f12efb |
|
26-Mar-2013 |
Chet Haase <chet@google.com> |
Make adding views specific to a ViewGroup's overlay
Adding views to views (possible with the new Overlay API) is weird.
This change moves the view-management facilities of Overlay to a subclass
that is specific to the overlay returned from ViewGroup.getOverlay().
So now you can add drawables to all view overlays, but only add/remove
views to/from the overlay returned from ViewGroup.getOverlay().
Also, the previous approach of using an interface for Overlay was
changed to classes for both ViewOverlay and ViewGroupOverlay.
Finally, this change makes not handling touch correctly the proper,
and documented, behavior of overlay views. There are various tricky issues
to sort out with input in overlays (including click handling as well as focus)
and we don't want developers starting to use overlays as some kind of general
container hierarchy, so we're purposely constraining overlays to have visual-only
behavior.
Issue #8459085 Overlay needs to handle touch correctly
Change-Id: I207b8dbf528f87c92369d270d8b0a6556826d207
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| 9c17fe693deb0cc84099b619185472f192c2b52d |
|
23-Mar-2013 |
Chet Haase <chet@google.com> |
Fix touch processing for Overlay views
Previous implementation processed Overlay touch after other children in
a ViewGroup; it should be the other way around.
Also, fixed some invalidation issues.
Finally, added new behavior to automatically place View which is already
parented into the same global position, by calculating where the overlay is
on the screen relative to the previous parent of the View.
Issue #8459085 Overlay needs to handle touch correctly
Change-Id: Ic2cee12d2bc345f64ed3f4d855a5c3496967a201
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| 633326e29f008d2b86e523cfeedcbb2a0883181f |
|
21-Mar-2013 |
Chet Haase <chet@google.com> |
Manage drawable invalidation automatically for Overlays
Drawables added to a view's Overlay will now cause the Overlay to
be invalidated via the normal drawable-invalidation mechanism. That is,
changes to any of the drawables in the overlay should cause invalidation of
the proper area of the overlay and thus the hostView, causing the appropriate
area to be redrawn.
Also, fixed a bug in drawable invalidation so that bounds changes will now
correctly invalidate both the old and new bounds areas.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: Icae5fa0e420232ee17dc39be10084345bae8dbd8
/frameworks/base/core/java/android/view/ViewOverlay.java
|
| 91cedf1c3dbf7a52c2892294b2e5ba3e40ef3583 |
|
11-Mar-2013 |
Chet Haase <chet@google.com> |
Add overlays to views
It is useful, particularly in animations, to be able to add a view, or at
least some graphics, on top of a view. For example, to have a child of a layout
fade away, we might want to remove the child from that layout and then fade it out
gradually. Meanwhile, we have to have a place to put that view where it will be
drawn. We could do this in the content container sometimes, but this is not a
reliable workaround in the general case, and may obscure other siblings/parents of
the layout/view in the hierarchy. A better approach would be to place a view/graphic
temporarily in the layout itself.
This feature adds the ability to add one or more Views and Drawables to an "overlay"
layer, after which the view will handle drawing that extra content when it redraws itself.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I70bf78c46ee3db8bd87ea1cdc2ecb5c0747ccbf9
/frameworks/base/core/java/android/view/ViewOverlay.java
|