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
HWComposer didn't allow the virtual display output buffer to be set
directly, instead it always used the framebuffer target buffer.
DisplayDevice was only providing the framebuffer release fence to
DisplaySurfaces after a commit.
This change fixes both of these, so both HWComposer and DisplayDevice
should continue to work if VirtualDisplaySurface changes to use
separate framebuffer and output buffers. It's also more correct since
VirtualDisplaySurface uses the correct release fence when queueing the
buffer to the sink.
Bug: 8384764
Change-Id: I95c71e8d4f67705e23f122259ec8dd5dbce70dcf
Previously we only queued a virtual display buffer to the sink when
the next frame was about to be displayed. This may delay the "last"
frame of an animation indefinitely. Now we queue the buffer as soon as
HWC set() returns and gives us the release fence.
Bug: 8384764
Change-Id: I3844a188e0f6ef6ff28f3e11477cfa063a924b1a
DisplayDevice now has a DisplaySurface instead of using
FramebufferSurface directly. FramebufferSurface implements
DisplaySurface, and so does the new VirtualDisplaySurface class.
DisplayDevice now always has a surface, not just for virtual displays.
In this change VirtualDisplaySurface is just a stub; buffers still go
directly from GLES to the final consumer.
Bug: 8384764
Change-Id: I57cb668edbc6c37bfebda90b9222d435bf589f37
None of these should change behavior, except for removing some
incorrect log messages when using a virtual display.
- HWComposer::getAndResetReleaseFenceFd() checks the HWC version, so
no need to do that in the DisplayDevice::onSwapBuffersCompleted().
However, it should check that mFramebufferSurface is not NULL like
it is for virtual displays.
- Comment that FramebufferSurface::dump() overrides the non-virtual
ConsumerBase::dump(), and fix it so the right thing happens
regardless of the static type of the pointer/reference the callee
has. FramebufferSurface::dump() could be removed right now, but I'd
need to bring it back in a later change.
- Use the right enum for validating display type ids.
- Don't try to send hotplug events for virtual displays.
- Mark virtual displays as connected so HWComposer::prepare() doesn't
think something is wrong when it gets a non-NULL layer list.
- Remove unused FramebufferSurface methods.
Bug: 8384764
Change-Id: Id28a2f9be86b45f4bb7915fdf7752157035f4294
FramebufferSurface no longer speaks directly to the FB HAL. Now
everything goes through HWComposer (which may or may not be
connected to a hardware composer).
Added display index arg to some query methods.
Change-Id: Id3e157d2d4e3555d33afbb703e518b6e92e2d6d5
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
This change is a clean up of some of the handling of the maximum number of
buffers that are allowed at once. It mostly renames a few member variables and
methods, but it includes a couple small refactorings.
Change-Id: I9959310f563d09583548d4291e1050a7bbc7d87d
This change refactors the FramebufferSurface class to inherit from the new
ConsumerBase class.
Bug: 6620200
Change-Id: I46ec942ddb019658e3c5e79465548b171b2261f2
After a HWC set, each SurfaceFlinger Layer retrieves the release fence
HWC returned and gives it to the layer's SurfaceTexture. The
SurfaceTexture accumulates the fences into a merged fence until the
next updateTexImage, then passes the merged fence to the BufferQueue
in releaseBuffer.
In a follow-on change, BufferQueue will return the fence along with
the buffer slot in dequeueBuffer. For now, dequeueBuffer waits for the
fence to signal before returning.
The releaseFence default value for BufferQueue::releaseBuffer() is
temporary to avoid transient build breaks with a multi-project
checkin. It'll disappear in the next change.
Change-Id: Iaa9a0d5775235585d9cbf453d3a64623d08013d9
SF now has its own implementation of ANW for the
framebuffer and it uses BufferQueue. FramebufferNativeWindow
is now only used by stand-alone apps.
Change-Id: Iddeb24087df62bd92b0f78e391dda9b97ddc859c
