summaryrefslogtreecommitdiffstats
path: root/core/jni/android_view_MotionEvent.h
Commit message (Collapse)AuthorAgeFilesLines
* Improve VelocityTracker numerical stability.Jeff Brown2011-03-151-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | Replaced VelocityTracker with a faster and more accurate native implementation. This avoids the duplicate maintenance overhead of having two implementations. The new algorithm requires that the sample duration be at least 10ms in order to contribute to the velocity calculation. This ensures that the velocity is not severely overestimated when samples arrive in bursts. The new algorithm computes the exponentially weighted moving average using weights based on the relative duration of successive sample periods. The new algorithm is also more careful about how it handles individual pointers going down or up and their effects on the collected movement traces. The intent is to preserve the last known velocity of pointers as they go up while also ensuring that other motion samples do not count twice in that case. Bug: 4086785 Change-Id: I2632321232c64d6b8faacdb929e33f60e64dcdd3
* Ensure the ShortcutManager uses the correct key character map.Jeff Brown2010-11-301-5/+9
| | | | | | | | | | | | | | | | | The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
* Add support for new input sources.Jeff Brown2010-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Added several new coordinate values to MotionEvents to capture touch major/minor area, tool major/minor area and orientation. Renamed NDK input constants per convention. Added InputDevice class in Java which will eventually provide useful information about available input devices. Added APIs for manufacturing new MotionEvent objects with multiple pointers and all necessary coordinate data. Fixed a bug in the input dispatcher where it could get stuck with a pointer down forever. Fixed a bug in the WindowManager where the input window list could end up containing stale removed windows. Fixed a bug in the WindowManager where the input channel was being removed only after the final animation transition had taken place which caused spurious WINDOW DIED log messages to be printed. Change-Id: Ie55084da319b20aad29b28a0499b8dd98bb5da68
* Native input dispatch rewrite work in progress.Jeff Brown2010-06-131-0/+38
The old dispatch mechanism has been left in place and continues to be used by default for now. To enable native input dispatch, edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy. Includes part of the new input event NDK API. Some details TBD. To wire up input dispatch, as the ViewRoot adds a window to the window session it receives an InputChannel object as an output argument. The InputChannel encapsulates the file descriptors for a shared memory region and two pipe end-points. The ViewRoot then provides the InputChannel to the InputQueue. Behind the scenes, InputQueue simply attaches handlers to the native PollLoop object that underlies the MessageQueue. This way MessageQueue doesn't need to know anything about input dispatch per-se, it just exposes (in native code) a PollLoop that other components can use to monitor file descriptor state changes. There can be zero or more targets for any given input event. Each input target is specified by its input channel and some parameters including flags, an X/Y coordinate offset, and the dispatch timeout. An input target can request either synchronous dispatch (for foreground apps) or asynchronous dispatch (fire-and-forget for wallpapers and "outside" targets). Currently, finding the appropriate input targets for an event requires a call back into the WindowManagerServer from native code. In the future this will be refactored to avoid most of these callbacks except as required to handle pending focus transitions. End-to-end event dispatch mostly works! To do: event injection, rate limiting, ANRs, testing, optimization, etc. Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25