This adds a second createBufferQueue method that returns
sp<IGraphicBuffer*> interfaces instead of sp<BnGraphicBuffer*>, since
most clients don't actually need the Binderized versions (but some
might).
Change-Id: Iaf4f719c96ddb6f704afc75cf52be22588173e32
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
Adds detachBuffer and attachBuffer calls to both the producer and
consumer sides of BufferQueue. Buffers may be detached while dequeued
by the producer or acquired by the consumer, and when attached, enter
the dequeued and acquired states, respectively.
Bug: 13173343
Change-Id: Ic152692b0a94d99e0135b9bfa62747dab2a54220
Now that BufferQueue has been split into core + producer + consumer,
rewrite BufferQueue to be a thin layer over a producer and consumer
interface. Eventually, this layer will be deprecated in favor of
only using either the producer or consumer interface, as applicable.
Change-Id: I340ae5f5b633b244fb594615ff52ba50b9e2f7e4
* Basic tests only. Needs more complicated queue/dequeue tests.
* Also needs consumer-side tests to really be thorough.
Change-Id: I1099dd56d65b6e9dfa15377726d6054ce657c0ca
When a BufferQueue producer disconnects and reconnects, we retain
the previously-queued buffers but empty the slots. This allows
the number of queued buffers to grow without limit. The low-memory
killer does not approve.
Bug 11069934
Change-Id: Ia2eaa954c7a3904b54209a3701dba01689e204d8
we add a flag to ANativeWindow::setBufferTransform that means
"apply the inverse rotation of the display this buffer is displayed
onto to".
Bug: 10804238
Change-Id: Id2447676271950463e8dbcef1b95935c5c3f32b2
This change adds an entire field to note whether the timestamp was
auto-generated by Surface or supplied by the application.
The value is used when deciding whether or not to drop frames based
on buffer presentation timestamps. If a desired presentation time
was set explicitly, BufferQueue will use that value to decide if a
frame should be dropped. If the timestamp was generated by Surface
at the time the buffer was queued, the timestamp is ignored.
Bug 10151804
Change-Id: Ibd571a7578351063b813cbdad2ddbeed70655ba5
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
Disable dropping of frames based on timestamp. Resume auto-
generating timestamps in Surface.
Bug 10151804
Change-Id: I15de26158e1d7ef22a5b150e685a126dc48ae2b4
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
If there are two or more buffers pending that are ready for
immediate presentation, drop all but the last one.
Any code that didn't explicitly specify timestamps for buffers
was using the default value (auto-generated "now"). As a result,
surfaceflinger would drop frames whenever more than one buffer
was queued. We now use zero as the auto-generated timestamp,
and we don't set the timestamp in eglBeginFrame().
Change-Id: I187f42d33de227cd3411ff0dcd3b9ce1961457eb
BufferQueue::dequeueBuffer() could incorrectly return
WOULD_BLOCK while in "cannot block" mode if it happened
while a consumer acquired the last allowed buffer
before releasing the old one (which is a valid thing
to do).
Change-Id: I318e5408871ba85e068ea9ef4dc9b578f1bb1043
we can now queue/dequeue a buffer in asynchrnous mode by using the
async parameter to these calls. async mode is only specified
with those calls (it is not modal anymore).
as a consequence it can only be specified when the buffer count
is not overidden, as error is returned otherwise.
Change-Id: Ic63f4f96f671cb9d65c4cecbcc192615e09a8b6b
we tag queued buffers with the "bufferqueue cannot block" flag
and use that bit to discard a buffer in the queue by new ones
comming in. this allows us to remove the buffer queue drain in
disconnect while maintaining the right behaviour if it gets
connected again (since each buffer remembers how it was enqueued).
Change-Id: I1e703d363a687b70b19ba49cef32213116e8bd3f
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
Now that we are having separate buffer-instances for the buffer-
queue, we can free all buffers; we don't have to keep the head
alive.
Change-Id: I023e9161a2501d99333f8868ce438afa914ec50f
Signed-off-by: Lajos Molnar <lajos@google.com>
Related-to-bug: 7093648
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
When disconnecting from BufferQueue, we now drain the queue
except the head (which means in the screenshot case we won't
have to block, but we might not have a buffer to show, this
will appear as an error in the log).
Bug: 8362363
Change-Id: If80989aac3c917beea2ebddf3cbb502849d394da
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
Rearranges updateTexImage() so that the SurfaceFlinger-specific
behavior is in a new SurfaceFlingerConsumer subclass.
SurfaceTexture behavior should not be altered. Instead of
acquire-bind-release we now do acquire-release-bind, but since
it's all done with the lock held there shouldn't be any
externally-visible change.
Change-Id: Ia566e4727945e2cfb9359fc6d2a8f8af64d7b7b7
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
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
This change adds debug info to SurfaceFlinger's dumpsys to indicate that the
USE_WAIT_SYNC compile option was enabled, and it removes the
ALLOW_DEQUEUE_CURRENT_BUFFER option.
Bug: 7238122
Change-Id: I70e08e34c2ef58aa6d2f88229e781a119f84b5a9
The hints were being set a little too late, so the pre-rotation stuff
wasn't quite working.
Bug 7054997
Change-Id: Id8d5c626db7a76f768ba762a145b315878ee08e6
