27285821b74ca9bc381d33f40028f06ff0f85e0c |
|
18-Dec-2013 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Use long for pointers in DisplayEventReceiver For storing pointers, long is used as native pointers can be 64-bit. In addition, some minor changes have been done to conform with standard JNI practice (e.g. use of jint instead of int in JNI function prototypes) Change-Id: I3c0855373c0e4bedc172adb82b103586de9219dc Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
82b007d7572dceb0981b269338bd1ac6c40496c5 |
|
13-Dec-2013 |
Brian Carlstrom <bdc@google.com> |
Track Looper decoupling from ALooper Change-Id: I54f4d36f105e60eaaa453ae60f591d634c681fd7
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
16823bd611689e9b5c0e1b675fee43579f85612a |
|
19-Nov-2012 |
Jesse Hall <jessehall@google.com> |
Process all display events in order Display events in each batch received from IPC were being processed in reverse order, and stopped after the first vsync event (latest chronologically) was handled. This makes perfect sense for vsync events, but is broken for hotplug events. Now we process them all in order, handling all except vsync as we see them. For vsync events, only the last is reported. Bug: 7491120 Change-Id: I04528fea8f38c1013734d4aa92fb1955ac24d7cc
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
e87bf030766198bf5e1fe846167dba766e27fb3f |
|
21-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Support HDMI hotplug. Bug: 7206678 Change-Id: Ia5212b16658a5f5a2ccf8528eca7bebd45ca857a
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
80a1de1007ddc62e1af2a4746008f499145aeaab |
|
01-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Use sp<LooperCallback> to fix race causing dangling pointer. Bug: 6559630 Change-Id: I9b9c76577779841006f9c024a80685ba8b7cd0e1
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
603b44589682db3ff33ade172facb0c5e309f1be |
|
07-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Ensure that apps crash if they throw exceptions. Previously, if an app threw an uncaught exception in an input, vsync or native activity callback, it would log the exception then continue limping merrily along. In the case of input, it could result in an ANR occurring because we had not drained all of the pending input events and marked them as finished (we only marked the most recent one finished). Bug: 6304124 Change-Id: I87d76f7fd605e1a8af1237c66d8d62973080277e
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
bec0a8682c75a40df6d0dca17e23db2103a950f3 |
|
29-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor DisplayEventReceiver read loop. Change-Id: I98ef802ec0ca48f768e3b0920e1b4b4f7f141050
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
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/jni/android_view_DisplayEventReceiver.cpp
|
3762c311729fe9f3af085c14c5c1fb471d994c03 |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/#/c/157220 Bug: 5449033 Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
8564c8da817a845353d213acd8636b76f567b234 |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGW(_IF) to (IF_)ALOGW(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/157065 Bug: 5449033 Change-Id: I00a4b904f9449e6f93b7fd35eac28640d7929e69
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
6779df2c28a68616134b1988f009221652d9f2ad |
|
07-Dec-2011 |
Mathias Agopian <mathias@google.com> |
Improve the VSYNC api a bit. - add the ability to set the vsync delivery rate, when the rate is set to N>1 (ie: receive every N vsync), SF process' is woken up for all of vsync, but clients only see the every N events. - add the concept of one-shot vsync events, with a call-back to request the next one. currently the call-back is a binder IPC. Change-Id: I09f71df0b0ba0d88ed997645e2e2497d553c9a1b
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|
0a0a1248cfc03940174cbd9af677bafd7280a3bc |
|
02-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Add a new class to receive vsync events. Change-Id: I4e384336d2813752a6d65fda6a77e86113a4510c
/frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
|