The previous logic in AnimationSet when starting an animation
ignored the fillBefore behavior of its child animations. This caused
a bug where a delayed AlphaAnimation would automatically cause the
target view to become transparent, even though it was supposed to wait
until after some delay to do so.
The fix checks the fillBefore behavior of each child animation before
concatenating its transform with the transform of the AnimationSet.
Change-Id: I76a2dafbe6dd338dc5281b17612eae87af168d86
Currently, you must call initialize() on RotateAnimation or
ScaleAnimation prior to calling start(). The reason is that the
actual pivot point used in calculating the transform is not set
until that method is called. This makes sense in the typical case
where the animation is running on a View and is using values relative
to the size of the View or of its parent. But if the caller sets the
values to be ABSOLUTE types instead, the sizes of the view and the parent
are irrelevant and the call to initialize() should not be needed (and
is not intuitive).
This fix automatically sets the internal pivot values in the case where
the value types are ABSOLUTE.
Change-Id: I74a0e462486efae08aa76e72c0d19d82f2a2677e
The various Properties added to View in 4.0 (ALPHA, TRANSLATION_X, etc.)
were not final, making it possible to assign on property to another.
Not something that someone would want to do, but we should try to prevent
that kind of mess. This API change makes those properties final.
Change-Id: I7d0c7f738eb2074d0781b1ba6a7c19339bac4477
...rotating to landscape
When doing spell checking in the same process as the spell checker, we
need to make sure it is still done asynchronously.
Putting this in I noticed quite a few threading issues in this code, so
I also addressed those (which became very obviously a problem with the
async stuff here now).
Also tweaked the service side to run spell checking at background priority.
Change-Id: I01bafe3bec6bceeca911d6bf2f61a486a2fd4c48
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
This change fixes an issue on some tiler architectures that do not
enable the swap buffer behavior by default on EGL surfaces.
Change-Id: Ibda1ae582da1a20afad3be9c3361080e72df5206
Bug: 5409969
If the current stream being displayed is different from the
stream being adjusted, rearrange the sliders, unless multiple
sliders are being shown.
Change-Id: Ia48986c1046305d7fee7a32177d78d8ffd84a11b
Some widgets apparently inject keys into the ViewRoot by sending
a DISPATCH_KEY message to its handler. Ugh.
Bug: 5711577
Change-Id: Ibe9aaf705095d152ec866c536f31f5d85e27b97f
Our typical touchscreens are now good enough that we don't need the
touch slop to be as large as it once was. Lower it to increase
responsiveness while scrolling.
Move the touch slop constant to the config resource
config_viewConfigurationTouchSlop so that it may be more easily
tweaked in device-specific overlays.
Change-Id: I7c11d8affcb98e91654203beb13a26cfeec18f7c
Both animations and drawing need to march to the beat of
the same drum, but the animation system doesn't know
abgout the view system and vice-versa so neither one
can drive the other.
We introduce the Choreographer as a drummer to keep
everyone in time and ensure a magnificent performance.
This patch enabled VSync based animations and drawing by
default. Two system properties are provided for testing
purposes to control the behavior.
"debug.choreographer.vsync": Enables vsync based animation
timing. Defaults to true. When false, animations are
timed by posting delayed messages to a message queue in
the same way they used to be before this patch.
"debug.choreographer.animdraw": Enables the use of the animation
timer to drive drawing such that drawing is synchronized with
animations (in other words, with vsync or the timing loop).
Defaults to true. When false, layout traversals and drawing
are posted to the message queue for execution without any delay or
synchronization in the same way they used to be before this patch.
Stubbed out part of the layoutlib animation code because it
depends on the old timing loop (opened bug 5712395)
Change-Id: I186d9518648e89bc3e809e393e9a9148bbbecc4d
...Background Replacement on Stingray
This is how I should have done it in the first place. We get the
new surface from the window manager, and then just copy it in to
the constant Surface object we have for the holder.
Change-Id: I537a9e413829a18f689dfb46687014676b27156e
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
getChildVisibleRect and getLocationInWindow do not take the new
mTransformationInfo View attribute.
As a result, these methods return invalid value during an animation
Bug 5638710
Changes in Patch Set 2:
- temporary allocations removed using static thread local variables (method
calls are NOT reentrant).
- scroll should be handled *before* applying the transformation matrix.
Fixed the call order in View#getLocationInWindow()
Patch set 4: fix from comments.
Patch set 5: <p>s
Change-Id: I15dc44c0659305d9029c59a47aba3a738bb35ae1
As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency
optimization.
This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.
Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
