Currently, there are two instances of BufferItem: one inside of
IGraphicBufferConsumer, and a standalone one inside of libgui. They
only differ in the name of one of the fields, and we want to remove
the IGBC version. This changes things so that client code may be
incrementally switched over to the libgui version.
This is a squashed commit containing the following changes:
I64f495105f56cbf5803cea4aa6b072ea29b70cf5
I1394e693314429ada93427889f10b7b01c948053
I9c3bc8037fa9438d4d9080b8afb694219ef2f71f
I699ed0a6837076867ca756b28d1ffb2238f7a0d9
Iac8425e1241774304a131da2fb9dec6e82922f13
Change-Id: Ic4d51f5df6dbc70b376d13fceba2335b9bae4f3d
Enables -Weverything and -Werror, with just a few exceptions for
warnings we can't (or shouldn't need to) work around.
Cherry pick of I034abec27bf4020d84af60d7acc1939c59986dd6 plus a
couple of minor changes to CpuConsumer.cpp to make it work with a
prior change:
Uncomment CC_LOGV on line 46
Change C-style cast to static_cast on line 71
Change-Id: Iaec610477ea0122317b0578fb74caf2383d4cf08
Passes the BufferItem for the queued buffer to the onFrameAvailable
callback so the consumer can track the BufferQueue's contents. Also
adds an onFrameReplaced callback, which is necessary if the consumer
wants to do anything more than simple queue length tracking.
Bug: 18111837
Change-Id: If9d07229c9b586c668e5f99074e9b63b0468feb0
In C++11 mode, "foo"MACRO_THAT_EXPANDS_TO_STRING gets lexed as a user
defined literal. Add space around the macro.
Change-Id: I2741f5be9c0b1562e0f413d1309ef9d687e89b41
Increases NUM_BUFFER_SLOTS from 32 to 64 and changes the mask
returned by IGBC::getReleasedBuffers from 32 to 64 bits.
Bug: 13174352
Change-Id: Ie8ef0853916cfb91f83881c7241886bb1950f01a
Sideband streams are essentially a device-specific buffer queue that
bypasses the BufferQueue system. They can be used for situations with
hard real-time requirements like high-quality TV and video playback
with A/V sync. A handle to the stream is provided by the source HAL,
and attached to a BufferQueue. The sink HAL can read buffers via the
stream handle rather than acquiring individual buffers from the
BufferQueue.
Change-Id: Ib3f262eddfc520f4bbe3d9b91753ed7dd09d3a9b
this means they only have access to the consumer end of
the interface. we had a lot of code that assumed consumers
where holding a BufferQueue (i.e.: both ends), so most of
this change is untangling in fix that
Bug: 9265647
Change-Id: Ic2e2596ee14c7535f51bf26d9a897a0fc036d22c
While currently untested, this should allow to move the
BuffereQueue in the consumer process and have everything
work as usual.
Bug: 9265647
Change-Id: I9ca8f099f7c65b9a27b7e7a3643b46d1b58eacfc
this is the first step of a series of improvements to
BufferQueue. A few things happen in this change:
- setSynchronousMode() goes away as well as the SynchronousModeAllowed flag
- BufferQueue now defaults to (what used to be) synchronous mode
- a new "controlled by app" flag is passed when creating consumers and producers
those flags are used to put the BufferQueue in a mode where it
will never block if both flags are set. This is achieved by:
- returning an error from dequeueBuffer() if it would block
- making sure a buffer is always available by replacing
the previous buffer with the new one in queueBuffer()
(note: this is similar to what asynchrnous mode used to be)
Note: in this change EGL's swap-interval 0 is broken; this will be
fixed in another change.
Change-Id: I691f9507d6e2e158287e3039f2a79a4d4434211d
When acquiring a buffer, SurfaceFlinger now computes the expected
presentation time and passes it to the BufferQueue acquireBuffer()
method. If it's not yet time to display the buffer, acquireBuffer()
returns PRESENT_LATER instead of a buffer.
The current implementation of the expected-present-time computation
uses approximations and guesswork.
Bug 7900302
Change-Id: If9345611c5983a11a811935aaf27d6388a5036f1
Instead of representing the buffer-queue as a vector of buffer
indices, represent them as a vector of BufferItems (copies).
This allows modifying the buffer slots independent of the queued
buffers.
As part of this change, BufferSlot properties that are only
been relevant in the buffer-queue have been removed.
Also, invalid scalingMode in queueBuffer now returns an error.
ConsumerBase has also changed to allow reuse of the same
buffer slots by different buffers.
Change-Id: If2a698fa142b67c69ad41b8eaca6e127eb3ef75b
Signed-off-by: Lajos Molnar <lajos@google.com>
Related-to-bug: 7093648
This moves the call to ConsumerBase::abandon from the ConsumerBase dtor to
ConsumerBase::onLastStrongRef. The abandon call relies on virtual methods to
perform the clean-up, so calling it from the ConsumerBase dtor after the
derived classes dtors ran was skipping some of the clean-up. The
onLastStrongRef method should get called just before the most derived class's
dtor gets called.
Bug: 8349135
Change-Id: I836946826927cc1ed69c049049f525f92b17a269
We now detect at runtime which sync features to use, which
allows us to remove a lot of the compile-time configuration
options. There is still one option though, to disable
KHR_fence_sync on some devices (which are more efficient
without it).
- added a backdoor to get the vendor's EGL strings
the new logic is:
- use always ANDROID_native_fence_sync if available
- fallback to KHR_fence_sync if available and not disabled
by the compile-time option
- use KHR_wait_sync if available and either of the above is
enabled
Change-Id: I9c4b49d9ff1151faf902cc93bd53ea5f205aaabf
This change eliminates the uses of a NULL sp<Fence> indicating that no waiting
is required. Instead we use a non-NULL but invalid Fence object for which the
wait methods will return immediately.
Bug: 7892871
Change-Id: I5360aebe3090422ef6920d56c99fc4eedc642e48
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: Ia03e468888025b5cae3c0ee1995434515dbea387
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
This prevents strong reference cycles when the listener implementation also
holds a strong pointer to the ConsumerBase
Bug: 7425644
Change-Id: I1514b13a32b18d421c902dddebec0765a989c55c
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
This change moves some common fence handling code into the base class for
BufferQueue consumer classes. It also makes the ConsumerBase class initialize
a buffer slot's fence with the acquire fence every time a buffer is acquired.
Change-Id: I0bd88bc269e919653b659bfb3ebfb04dd61692a0
This change makes SurfaceTexture inherit from ConsumerBase. It removes all of
the functionality from SurfaceTexture that is now provided by the base class.
This includes fixes for two bugs that were found after checking this change in
the first time and then reverting it.
Change-Id: Ie2d9f4f27cfef26fdac341de3152e842b01a58d2
This change makes SurfaceTexture inherit from ConsumerBase. It removes all of
the functionality from SurfaceTexture that is now provided by the base class.
Change-Id: I4a881df42810a14ee32d4ef7c8772a8f2510f4c7
This change refactors the FramebufferSurface class to inherit from the new
ConsumerBase class.
Bug: 6620200
Change-Id: I46ec942ddb019658e3c5e79465548b171b2261f2
