| 0e40462e11d27eb859b829b112cecb8c6f0d7afb |
|
13-May-2015 |
John Reck <jreck@google.com> |
Revert "DO NOT MERGE Backport of limited jank-tracking metrics"
This reverts commit 2614bd225f84f7a23e6b30fc6b47bede153e5f4c.
Change-Id: I344b4cbaa0bb0caf50bceb806d1446ee27ea52d8
/frameworks/base/core/java/android/view/Choreographer.java
|
| d5a4a1aac980c304d6f46f07f15bfc5c94d8f9d0 |
|
19-Feb-2015 |
John Reck <jreck@google.com> |
DO NOT MERGE Backport of limited jank-tracking metrics
Bug: 19821830
Cherry-pick of ba6adf66d3c44c0aa2fd8a224862ff1901d64300
Cherry-pick of e70c5754d01f2ab0ff47ea3eabaa88aca5ed2a36
Change-Id: Id342fa0ab345f204bec58acf45ce72f6de950cfb
/frameworks/base/core/java/android/view/Choreographer.java
|
| 8d8af3c1b768d590754d657a7d1242dcb462454b |
|
02-Jul-2014 |
John Reck <jreck@google.com> |
Fixes to startDelay
Bug: 15991758
Don't update the UI thread with final value until after
startDelay
Change-Id: Ie8bffb5a3ace353ec1d82943a4efcbd01c42c28f
/frameworks/base/core/java/android/view/Choreographer.java
|
| 315c329544d7c593d1072b071cbb92d9afe74021 |
|
10-May-2014 |
John Reck <jreck@google.com> |
Add TimeInterpolator support to RNA
Bug: 14678626
Change-Id: I6554e7fcd42c49fac3618ca792083bb68e358f55
/frameworks/base/core/java/android/view/Choreographer.java
|
| 18f16e6fba74eda173e1e7c869e6e2e2acc073ff |
|
03-May-2014 |
John Reck <jreck@google.com> |
TIME LORD!
Bug: 14444180
Change-Id: I68bec3807c4d1c88d5af1aec2fe6907d60b5f2f3
/frameworks/base/core/java/android/view/Choreographer.java
|
| 5182c780a8b42acd46a06d693ab63a0dd78c6d70 |
|
16-Oct-2013 |
Jeff Brown <jeffbrown@google.com> |
Log view root, input and looper state in bug reports.
Bug: 10948648
Change-Id: I956cce2a0fb516c02f9bbbc021f6238bcb226891
/frameworks/base/core/java/android/view/Choreographer.java
|
| 3866f0d581ceaa165710feeee9f37fe1b0d7067d |
|
12-Feb-2013 |
Mathias Agopian <mathias@google.com> |
split Surface in two classes: SurfaceControl and Surface
SurfaceControl is the window manager side; it can
control the attributes of a surface but cannot push buffers
to it. Surface on the other hand is the application (producer)
side and is used to push buffers to the surface.
Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
/frameworks/base/core/java/android/view/Choreographer.java
|
| e87bf030766198bf5e1fe846167dba766e27fb3f |
|
21-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Support HDMI hotplug.
Bug: 7206678
Change-Id: Ia5212b16658a5f5a2ccf8528eca7bebd45ca857a
/frameworks/base/core/java/android/view/Choreographer.java
|
| bd6e1500aedc5461e832f69e76341bff0e55fa2b |
|
28-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Add initial multi-display support.
Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
/frameworks/base/core/java/android/view/Choreographer.java
|
| 98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support.
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/core/java/android/view/Choreographer.java
|
| d32460c5b7bea7b06e345397fdbaca58d9732dcf |
|
21-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor local window manager implementation.
The objective of this refactoring is to remove the reliance on
WindowManager wrapper objects for compatibility mode and for
managing sub-windows.
Removed the WindowManager.isHardwareAccelerated() method since
it is never used.
Change-Id: I4840a6353121859a5e0c07d5cc307a437c595d63
/frameworks/base/core/java/android/view/Choreographer.java
|
| ba726113e525823f2594507d098f2d99426655f6 |
|
15-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Revert "Synthesize fake vsyncs when the screen is off."
This reverts commit 858491ba13ab5d45a5ec462d002b5856703b1b2b
It turns out that Surface Flinger is supposed to generate fake vsyncs while the screen is off, but sometimes it wasn't working due to a bug. That bug has now been fixed by the following change: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
/frameworks/base/core/java/android/view/Choreographer.java
|
| 858491ba13ab5d45a5ec462d002b5856703b1b2b |
|
15-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Synthesize fake vsyncs when the screen is off.
When the screen is off, we might not receive real vsync pulses from
the hardware which would cause posted Choreographer callbacks to not run.
This is bad because messages in the Looper might be blocked behind a barrier
that is scheduled to be removed by one of those Choreographer callback
(see ViewRootImpl.doTraversals). Until the barrier is removed, those messages
will not run. To prevent starvation of the Looper, we synthesize fake vsync
pulses at a reduced rate whenever the display hardware stops generating them.
This change should fix a variety of rare non-deterministic bugs where
the system might appear to be unresponsive while the screen is off,
and spurious ANRs reported shortly after the screen is turned back on.
Bug: 6574842
Bug: 6636995
Bug: 6643559
Change-Id: I263f2fdf979afd79e5ac47a0cc5d34a93b860c21
/frameworks/base/core/java/android/view/Choreographer.java
|
| 265f1ccc5128319d81eee70ee2d2ae81573efb11 |
|
12-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve ANR diagnostics.
When an ANR occurs, log the associated reason.
When an event takes too long to process (currently more than 2 seconds)
log basic information about the event including how long it actually
took.
Dump the contents of the inbound, outbound and wait queues as part
of dumpsys input.
Bug: 6574842
Change-Id: I9ab754c320f609cb86fe266c469a61e7032dfed6
/frameworks/base/core/java/android/view/Choreographer.java
|
| 4fdf9c6e2a177845bb4cc20f69b83555de209144 |
|
12-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Detect bad behavior earlier in Choreographer.
Detect wonky vsync timestamps (should they occur) and
warn loudly about them.
Warn when too many frames are skipped. The threshold is pretty
conservative right now (only warn if at least 30 frames are skipped)
but it can be adjusted using system property. Even skipping just a
couple of frames is enough to generate noticeable jank.
The threshold is currently intended to help track down bigger problems
such when an app does too much work on the UI thread.
Bug: 6574842
Change-Id: I4aac7e5e17d1fb51adb0510e318a72a28b3775ed
/frameworks/base/core/java/android/view/Choreographer.java
|
| cae804901eb5761e42d5bac7cdd6f15d37e3ceb3 |
|
22-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Add public API to Choreographer.
The API allows applications to post FrameCallbacks that will
run on vsync and that are provided with the frame time.
Change-Id: Ieb39fcdd085ef8a57805b8f78e7a307f416ff21d
/frameworks/base/core/java/android/view/Choreographer.java
|
| b080660dfd69ea6f0a034946b2ff8d94e97a2537 |
|
16-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix a possible starvation issue related to vsync.
This makes a noticeable improvement in cases where applications
post messages that need to be processed between animation frames.
Bug: 6418353
Change-Id: If225742e37aeaf3f0ca9710f9bf43dbb03bcde12
/frameworks/base/core/java/android/view/Choreographer.java
|
| 59bbef0cd781f4933fd8a0a85b6067f36e529e02 |
|
08-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve animation timing.
Detect when a vsync message was significantly delayed which may
indicate that a frame was skipped. When this happens, update
the frame time to reflect the approximate start time of the
current frame instead of the start time of the frame that was
skipped a long time ago.
Removed an unnecessary call to getCurrentPlayTime() in the
animator framework. The result was always zero and the call
just made the code confusing.
Bug: 6443611
Change-Id: I92b24f7ffd74c59b75a727b6bfc0bb51fc92a73a
/frameworks/base/core/java/android/view/Choreographer.java
|
| 20c4f87b2916d05e860d11568d7db6b2d340e909 |
|
27-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Use choreographer frame time to schedule animations.
Instead of using the current uptime millis, which can exhibit
substantial jitter depending on when the code runs, use the
current frame's vsync time when performing animations. The frame
time provides a more consistent pulse.
Bug: 6375101
Change-Id: Icf307cd8524246607db7496c6fef9a5eeb7c0439
/frameworks/base/core/java/android/view/Choreographer.java
|
| 97d5c418730946a0332f601cd140ed0b12ea19c1 |
|
27-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove unused pipelining optimization.
Bug: 6375101
Change-Id: I5fcbbabfafae9e1661adac7b2becc748e42c4b66
/frameworks/base/core/java/android/view/Choreographer.java
|
| ebb2d8d708c5c58c79ae88ac2bd10450a856f702 |
|
24-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Enable vsync traversals by default.
Improved how the various callbacks are managed and sequenced
to reduce code duplication.
Added a heuristic to avoid postponing traversals until
the next vsync frame if we did not actually do any drawing during
the previous frame. This helps in the very common case where
drawing occurs in response to input.
Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
/frameworks/base/core/java/android/view/Choreographer.java
|
| 43ea54bdc343a913f62885304796e4ab1bca4ef1 |
|
09-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Don't remove all animation callbacks if action/who was null.
Fixes a bug in View.removeCallbacks and View.unscheduleDrawable
where it was possible for the caller to remove all animation
callbacks if it happened to specify an action or who parameter
of null.
Also refactored the callback queueing code in Choreographer
to make it more intent revealing although the behavior remains
the same.
Bug: 6144688
Change-Id: Iba29dcda6b3aaad73af664bb63feab65ae3483e5
/frameworks/base/core/java/android/view/Choreographer.java
|
| 7ae9d5faad5816f7e567ec1ec77e78d746cf7e5c |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Use the Choreographer for Drawable animations.
Change-Id: Ifcbf33434bf3c32d1900fd0b3f5bde004604ce8a
/frameworks/base/core/java/android/view/Choreographer.java
|
| 5bebea436e631aa77aeb0f39a34c9e830c9638f5 |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Rename remove callback methods.
Change-Id: Ib9ef32fedbe0db2ea5efd250693915d626d7d8ae
/frameworks/base/core/java/android/view/Choreographer.java
|
| 2b6cb9a27e6f11fb30c9b9baaa5fc02f29f4072e |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Support posting delayed animation/draw callbacks.
This is especially useful for slow animations such as blinking the
cursor, which only needs to happen after a certain amount of time
has elapsed.
Change-Id: If1163a3480078c75d6461eb8f96d8bf8b625534f
/frameworks/base/core/java/android/view/Choreographer.java
|
| e0dbd002750856e55d637e883b629e09adfc8a4e |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Mark input and sensor messages as asynchronous.
Set a barrier on traversals.
Vsync is still not enabled by default in this patch so there
should be no observable effect from these changes.
Change-Id: Ie12081b95a8f1e81ed686edf747cc62f2e044b7e
/frameworks/base/core/java/android/view/Choreographer.java
|
| 1654d0b8d9ba477a0134338838b6e5921f1aabb8 |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Keep the display event receiver around forever.
There is really no point disposing the display event receiver
anymore. Moreover, it's hard to choose a good time to do it
since the Choreographer only supports one-shot callbacks now.
So let's made the code simpler.
Bug: 5721047
Change-Id: I8533a54e93a787e0ca30d99a1f1eea85534b13b9
/frameworks/base/core/java/android/view/Choreographer.java
|
| 4a06c8008b2edd6677f9a411af79b0a4971b87fe |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Simplify Choreographer API.
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
/frameworks/base/core/java/android/view/Choreographer.java
|
| 968588573cf516fd8cf33c133d06f06c67ca1785 |
|
14-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Add support for posting Runnables to the Choreographer.
Also clean up the Choreographer so that it doesn't directly extend
Handler and so that it doesn't schedule animation or drawing unless
there are listeners or callbacks attached.
Bug: 5721047
Change-Id: I35350c8d41d4fa3f8c8c7bc43edd82e581b55a68
/frameworks/base/core/java/android/view/Choreographer.java
|
| 58aedbc9bea13415e2d42cf7c9fe8a7efd243e66 |
|
14-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix possible races in vsync infrastructure.
Applications sometimes crashed on exit due to the display event
receiver pipe apparently being closed while still a member of the
Looper's epoll fd set.
This patch fixes a few different possible races related to
the display event receiver lifecycle.
1. The receiver used to play a little dance with the Looper,
registering and unregistering its callback after each vsync
request. This code was a holdover from a time before the
surface flinger supported one-shot vsync requests, so we can
get rid of it and make things a lot simpler.
2. When the Choreographer is being accessed from outside the UI
thread, it needs to take great care that it does not touch
the display event receiver. Bad things could happen if the receiver
is handling a vsync event on the Looper and the receiver is
disposed concurrently.
3. It was possible for the Choreographer to attempt to dispose
the receiver while handling a vsync message. Now we defer disposing
the receiver for a little while, which is also nice because we
may be able to avoid disposing the receiver altogether if we find
that we need it again a little while later.
Bug: 5974105
Change-Id: I77a158f51b0b689af34d07aee4245b969e6260d6
/frameworks/base/core/java/android/view/Choreographer.java
|
| 87d0b03f1f16590ff261ae30441e838ae5446e84 |
|
03-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Make the Choreographer thread-safe.
Change-Id: Ieb52cf3b8086e7cf743b45a8b92d4bd5957f43ee
/frameworks/base/core/java/android/view/Choreographer.java
|
| 8bcd54b98ad5d98d47364ff14e06910deadf9302 |
|
01-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
Use Choreographer for window manager animation timing.
Change-Id: Ic34aff698c63d383ecd06af7da9957475683a1db
/frameworks/base/core/java/android/view/Choreographer.java
|
| 90a3c5f51ddf0f98769a258ed224f2ec5b645d0e |
|
07-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Disable postponing performTraversals(), for now.
Bug: 5715378
Bug: 5721047
Change-Id: I89c674306665b6caa3a63b8a9d2b4b7c9ed020ae
/frameworks/base/core/java/android/view/Choreographer.java
|
| 96e942dabeeaaa9ab6df3a870668c6fe53d930da |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Use a Choreographer to schedule animation and drawing.
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
/frameworks/base/core/java/android/view/Choreographer.java
|