a931d5218cfee89c7629ffa6cde324fa966449f9 |
|
08-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Use long for pointers in view/input classes For storing pointers, long is used in view/input classes, 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: Iafda9f4653c023bcba95b873637d935d0b569f5d Signed-off-by: Ashok Bhat <ashok.bhat@arm.com> Signed-off-by: Marcus Oakland <marcus.oakland@arm.com> Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
62ce65d6edbc2c34c63b0e2f2fef9cb08e28c783 |
|
25-Oct-2013 |
Michael Wright <michaelwr@google.com> |
Speculatively schedule input consumption With the new tuned vsync offset, vsyncs are likely to occur shortly after the input is received, meaning we will empty the input queue, and thus won't schedule input consumption until more input is received. If an application then speculatively posts draw commands to the main looper faster than 60 hz, it will eventually end up blocking in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't even schedule consumption until after the current frame (8-16ms), and it's entirely likely we won't actually get around to consuming input until after the next frame (another 16 ms of latency). This means we can often go 16-32ms without processing any input events, causing very noticeable amounts of jank. Rather than waiting for the next input event to schedule input consumption, speculatively schedule it every frame as long as we've consumed some motion batch during this frame. Bug: 11398045 Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
a4ca8ea0ad14c509d1ced46482e83c1b8a518982 |
|
03-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Fix reference cycle in InputEventReceiver and Sender. If the receiver or sender was not properly disposed, then the underlying input channel might be leaked because the native peer was holding a strong reference to the object. Switched to using a weak reference. Also updated Binder to use a new helper created for this purpose. Change-Id: I19680bf96d0548777bff02aa1d91874d1e8e41da
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
3e7e7f025e8d7dc6ab8c361118c8e949bdf3e451 |
|
27-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix improper use of CloseGuard. Change-Id: I37131a86e27a4be55956384a3566de9dcfd90fe5
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
771526c88f5cc4b56a41cb12aa06a28d377a07d5 |
|
28-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Resample touch events on frame boundaries. Bug: 6375101 Change-Id: I8774e366306bb2b6b4e42b913525bf25b0380ec3
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
072ec96a4900d4616574733646ee46311cb5d2cb |
|
07-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Implement batching of input events on the consumer side. To support this feature, the input dispatcher now allows input events to be acknowledged out-of-order. As a result, the consumer can choose to defer handling an input event from one device (because it is building a big batch) while continuing to handle input events from other devices. The InputEventReceiver now sends a notification when a batch is pending. The ViewRoot handles this notification by scheduling a draw on the next sync. When the draw happens, the InputEventReceiver is instructed to consume all pending batched input events, the input event queue is fully processed (as much as possible), and then the ViewRoot performs traversals as usual. With these changes in place, the input dispatch latency is consistently less than one frame as long as the application itself isn't stalled. Input events are delivered to the application as soon as possible and are handled as soon as possible. In practice, it is no longer possible for an application to build up a huge backlog of touch events. This is part of a series of changes to improve input system pipelining. Bug: 5963420 Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
92cc2d8dc35f2bdd1bb95ab24787066371064899 |
|
02-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Remove type tests when recycling input events. Change-Id: I1c2d5980a763c457a0546bbf601e686c601a4c03
/frameworks/base/core/java/android/view/InputEventReceiver.java
|
32cbc3855c2a971aa5a801fd339fb6a37db91a1a |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Refactor InputQueue as InputEventReceiver. 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
/frameworks/base/core/java/android/view/InputEventReceiver.java
|