Third-party libraries are currently trying to use the
MemoryBase constructor but failing because we fixed the
definition of ssize_t. This is a stop-gap for users of
this private API until we can get them fixed.
Bug: 8253769
Change-Id: Ie7c86f45fa39cb53539cab0ffe8585a585656714
Third-party libraries are currently trying to use the
MemoryBase constructor but failing because we fixed the
definition of ssize_t. This is a stop-gap for users of
this private API until we can get them fixed.
Bug: 8253769
Change-Id: I8a19770f3252d88ee87023fde625cc6289924b0d
This change makes GraphicBufferAllocator::alloc wait for pending async frees to
complete before attempting to allocate a gralloc buffer if there are more than
8 pending async frees.
Bug: 7696861
Change-Id: I1fae86e13edefcaa153b8ce9fd057f335716059e
This change makes GraphicBufferAllocator::free queue a job to another thread to
perform the actual free operation. This prevents potentially slow free
operations from blocking rendering.
Bug: 7675940
Change-Id: Id61099d66bb4c3949d04184e0d7f192ac18076b4
This change makes ConsumerBase::onBuffersReleased hold a reference to all its
gralloc buffers until after the mutex is unlocked. This prevents slow
gralloc::free calls from causing lock contention with rendering threads.
Bug: 7675940
Change-Id: I0ec805d1b612afeeecfffec03f982371d27d93be
in this particular case, this OOB is always harmless
(and that's why it didn't get fixed from MR1), however,
it interfers with valgrind debugging.
Change-Id: Ic977e03287e59c4b124a89146c9023bd0cb540a8
The emulator doesn't support systrace, but we should point that out
at most once per process.
Bug 7436352
Change-Id: I06b2c1ea0df6c02c11cd2496423c337f8d7c62a1
This change adds support for displays that are not allowed to display surfaces
with the eSecure flag set. All non-virtual displays are considered secure,
while virtual displays have their secure-ness specified at creation time.
Bug: 7368436
Change-Id: I81ad535d2d1e5a7ff78269017e85b111f0098500
This change adds a transaction flag for WindowManager to indicate that a
transaction is being used to animate windows around the screen. SurfaceFlinger
will not allow more than one of these transactions to be outstanding at a time
to prevent the animation "frames" from being dropped.
Bug: 7353840
Change-Id: I6488a6e0e1ed13d27356d2203c9dc766dc6b1759
This change makes BufferQueue::dequeueBuffer release its mutex before
allocating new buffers. This should alleviate lock contention in
SurfaceFlinger where SF's main thread can get blocked waiting for an allocation
operation to complete.
Bug: 7335075
Change-Id: I1b000539cc616a695afab2e9c68507db69e57b13
error codes are returned in errno, this caused ::waitForwever()
to only wait for 1 second and return improper error code (-1).
needed to help debugging 7316632
Bug: 7316632
Change-Id: Ie144f614a88393393972a3a770c6b4b0581f961a
This needs the ConsumerBase mutex locked, but wasn't locking it. Two
of the four places that called it already held the lock so were fine.
Now addReleaseFence() takes the lock itself, and I added
addReleaseFenceLocked() for the two already-locked callers, since in
one of them dropping the lock would be inconvenient.
Bug: 7289269
Change-Id: I7a5628adb516f8eec782aa6c14128202f96d7b0a
