Commit Graph

14 Commits

Author SHA1 Message Date
Mathias Agopian
a9611c5d5b fix a corruption in Vector<> when adding new items
would happen when vectors are copied and new items is
added in both vectors. we didn't duplicate the underlying
storage when adding items in vectors.

Bug: 6515797
Change-Id: If544c07d96c05821e088d7f2c9b5736f7e306c31
2012-05-17 17:47:44 -07:00
Steve Block
6726347e89 Rename LOG_ASSERT to ALOG_ASSERT DO NOT MERGE
See https://android-git.corp.google.com/g/157519

Bug: 5449033
Change-Id: I8ceb2dba1b031a0fd68d15d146960d9ced62bbf3
2012-01-09 21:36:22 +00:00
Steve Block
6807e59e0f Rename (IF_)LOGV(_IF) to (IF_)ALOGV(_IF) DO NOT MERGE
See https://android-git.corp.google.com/g/#/c/143865

Bug: 5449033
Change-Id: I0122812ed6ff6f5b59fe4a43ab8bff0577adde0a
2011-10-26 09:57:54 +01:00
Jeff Brown
c105333997 Minor code cleanups in vector.
Fixed a potential bug where calling replaceAt with a reference to
an existing element in the vector at the same index would cause
the element to be destroyed while being copied to itself.

Refactored the conditions in _grow and _shrink for clarity.
The computations are exactly the same but I think it reads better
this way.  In particular, the ssize_t variable 's' is gone: it didn't
need to be signed anyways because its value could never be negative.

Change-Id: If087841c15e6a87160eee874720c4a77eb0e99a6
2011-07-14 04:11:23 -07:00
Jeff Brown
686f62fcaf Replace Vector _grow/_shrink checks with assert.
On review of the code, _grow and _shrink are checking for conditions
that cannot happen and that don't even really make sense.  For
example, if _shrink is called with where + amount > mCount then
this is really bad, however the check only considered the case
when where >= mCount and then it would arbitrarily choose a new
value for where.  Huh?

As it happens, the callers are correctly validating the
arguments before passing them down to these methods so we can
get rid of this code.

Change-Id: I921852dba8997065bb0e9cac733e82028d14afcd
2011-07-14 04:11:22 -07:00
Mathias Agopian
f6f177f2e2 Fix typo in an assert's log
Change-Id: I94883a23a0a92eaf3e4976f942f747a2137499ac
2011-07-11 16:26:18 -07:00
Jeff Brown
f4a4ec2063 Even more native input dispatch work in progress.
Added more tests.
Fixed a regression in Vector.
Fixed bugs in pointer tracking.
Fixed a starvation issue in PollLoop when setting or removing callbacks.
Fixed a couple of policy nits.

Modified the internal representation of MotionEvent to be more
efficient and more consistent.

Added code to skip/cancel virtual key processing when there are multiple
pointers down.  This helps to better disambiguate virtual key presses
from stray touches (such as cheek presses).

Change-Id: I2a7d2cce0195afb9125b23378baa94fd2fc6671c
2010-06-17 13:27:16 -07:00
Jeff Brown
e839a589bf Native input dispatch rewrite work in progress.
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
2010-06-13 17:42:16 -07:00
Dianne Hackborn
c85e12e075 Revert "fix [2542425] memory leak during video recording"
This reverts commit 544592e14f8d7643238e40ba9879727497900f35.
2010-03-30 21:04:17 -07:00
Mathias Agopian
77e26d6822 fix [2542425] memory leak during video recording
[Sorted|Keyed]Vector<TYPE> would leak their whole storage when resized
from the end and TYPE had trivial dtor and copy operators.

Change-Id: I8555bb1aa0863df72de27d67ae50e20706e90cf5
2010-03-30 19:02:59 -07:00
Mathias Agopian
caeddc7236 fix [2542425] memory leak during video recording
Vector::sort() is using _do_copy() incorrectly; _do_copy() calls the
copy constructor, not the assignment operator, so we need to destroy
the "destination" before copying the item.

Change-Id: Iaeeac808fa5341a7d219edeba4aa63d44f31473c
2010-03-29 13:45:18 -07:00
The Android Open Source Project
edbf3b6af7 auto import from //depot/cupcake/@135843 2009-03-03 19:31:44 -08:00
The Android Open Source Project
d5193d9394 auto import from //depot/cupcake/@135843 2009-03-03 18:28:45 -08:00
The Android Open Source Project
7c1b96a165 Initial Contribution 2008-10-21 07:00:00 -07:00