Move setDefaultBufferSize, setDefaultBufferFormat, and
setDefaultBufferDataSpace into ConsumerBase and remove them from
CpuConsumer and BufferItemConsumer.
Bug: 19977701
Change-Id: Ic68992464c5da6da7a41c4063a53029a69efcd1b
Removes IGraphicBufferConsumer::BufferItem. Depends on the
following changes:
I187b3a7d05196b6289596afac8fb9a9d4aebff76
I0ddd38df37500cfd6b21d1e768ed14e39c5cd9fc
Change-Id: Id1fa56d092188f2cb712768d5d2fc6a9027fb73c
Switches some dependencies from IGraphicBufferConsumer::BufferItem to
android::BufferItem and adds some methods to facilitate incrementally
changing client code to do the same.
Change-Id: I699ed0a6837076867ca756b28d1ffb2238f7a0d9
- Wire up new dataSpace parameter through buffer queue stack
- Update tests to include the parameter
- Switch eglApi to using dataSpace to indicate sRGB gamma/linear
difference
- Remove RAW_SENSOR in favor of RAW16
- Remove use of sRGB format enums
- Add default dataspace to buffer queue core
- Add query for default dataspace
Change-Id: I070bd2e7c56506055c419004c29e2e3feac725df
Enables -Weverything and -Werror, with just a few exceptions for
warnings we can't (or shouldn't need to) work around.
Change-Id: I034abec27bf4020d84af60d7acc1939c59986dd6
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
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
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
- timeout is now 3 seconds instead of 1
- simplifies the API a bit
- allows us to change/tweak this timeout globaly
Bug: 8988871
Change-Id: I8d3c6ec43a372f602fb3f29856710339f86c0ec9
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
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 BufferQueue derive the min undequeued buffer count from a max
acquired buffer count that is set by the consumer. This value may be set at
any time that a producer is not connected to the BufferQueue rather than at
BufferQueue construction time.
Change-Id: Icf9f1d91ec612a079968ba0a4621deffe48f4e22
BufferItemConsumer allows for acquiring BufferQueue's BufferItems,
which contain all the data and metadata the BufferQueue has for a
given graphics buffer.
This consumer is useful when direct access to the native buffer_handles
is needed by the client.
Also includes a minor cleanup of CpuConsumer's use of 'virtual'.
Bug: 6243944
Change-Id: If7dc4192b15ac499555f1eda42a85140f2434795
