ac04f4e69a6de138c5afc668a2c89b7da7ff4e6a |
|
23-Jun-2016 |
John Reck <jreck@google.com> |
Remove FD from the right Looper Bug: 29586513 Also gives BackdropFrameRenderer a direct-destroy of Choreographer since it's hammering on new Threads and we don't want to wait for the GC to release FDs. Change-Id: Id2ec0af2ee4d5304961c4ab87a104ccb92f35fc2
/frameworks/base/core/java/android/view/Choreographer.java
|
e22c59b2913578c24e86673576d009d34306f6be |
|
22-May-2015 |
Chris Craik <ccraik@google.com> |
Trace each stage of Choreographer driven frames bug:21374535 Change-Id: I332dac216defbc4517441e2a9cdffdf71731f1e6
/frameworks/base/core/java/android/view/Choreographer.java
|
b3b9eb3cfc5b3b3609a5d01258315798b38a5cf9 |
|
12-May-2015 |
P.Y. Laligand <pylaligand@google.com> |
DO NOT MERGE - Display mode switches. Knowledge of the various modes of a display is now available to apps, and they can request a specific mode for their windows. b/18241736 Change-Id: I8eb16ff713e878512faca3ca6662254f08a9be7f (cherry picked from commit 5c7773d86484aac5737667c604bd8fe8150c2136)
/frameworks/base/core/java/android/view/Choreographer.java
|
c42b28dda45347b05826dc3e04f5605a60867a63 |
|
07-Apr-2015 |
Jeff Brown <jeffbrown@google.com> |
Fix animation start jank due to expensive layout operations. The Choreographer carefully schedules animation updates to occur after input but before traversals occur. This ensures that the effects of animations are perceived immediately in the next frame. The start time of animation is usually set the moment the animator first runs. The start time serves as a reference for timing the remainder of the animation. Setting the start time during the animation callback works well except when traversals take a long time to complete. In that case, we may end up drawing the initial frame of the animation then skipping several following frames (because a lot of time has already passed since the animation start time was set), effectively shortening the duration of the animation. To resolve this issue, we introduce a new COMMIT phase within the Choreographer. The COMMIT callback runs after traversals complete and may provide an updated frame time that more accurately reflects the time when the frame finished drawing. In the case where an animation is just starting, we note the fact that its initial start time has not yet been committed (the user hasn't actually seen anything on screen yet). Then, during the COMMIT phase, we adjust the animation start time to better reflect the time when the animation's first frame was drawn, effectively causing the animation actually start after the expensive traversal operations occurred such that no frames will be skipped. Bug: 17258911 Change-Id: I279603d01fd4ed1de8f51a77c62f4fec5e9b746a
/frameworks/base/core/java/android/view/Choreographer.java
|
ba6adf66d3c44c0aa2fd8a224862ff1901d64300 |
|
19-Feb-2015 |
John Reck <jreck@google.com> |
Initial attempt at jank-tracking stat collection Is a bit naive, perhaps overly aggressive, but sorta works Change-Id: I01a774e00dbe681439c02557d9728ae43c45ce50
/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
|