This changes the way that SurfaceFlinger's shadow buffer management
works such that instead of tracking the size of the shadow queue in the
BufferQueue, SF tracks the last frame number it has seen, and passes
that into the acquireBuffer call. BufferQueueConsumer then ensures that
it never returns a buffer newer than that frame number, even if that
means that it must return PRESENT_LATER for an otherwise valid buffer.
Change-Id: I3fcb45f683ed660c3f18a8b85ae1f8a962ba6f0e
When a Layer's sideband stream is set, apply any pending transactions.
Otherwise they would never be applied since sideband streams don't
trigger updates by pushing new buffers.
Bug: 20125898
Change-Id: I0c7a91cdf84e6205801f4ab64eee0b09e4c0b3e0
(cherry picked from commit 3b04e1383eca6cb1d43ebe23a421c427007690c7)
SurfaceFlinger's (Layer's) shadow copy of the BufferQueue queue was
getting out of sync for a few reasons. This change fixes these by
doing the following:
- Adds a check to re-synchronize the shadow copy every time we
successfully acquire a buffer by first dropping stale buffers before
removing the current buffer.
- Avoids trying to perform updates for buffers which have been rejected
(for incorrect dimensions) by SurfaceFlinger.
- Adds IGraphicBufferConsumer::setShadowQueueSize, which allows the
consumer to notify the BufferQueue that it is maintaining a shadow
copy of the queue and prevents it from dropping so many buffers
during acquireBuffer that it ends up returning a buffer for which the
consumer has not yet received an onFrameAvailable call.
Bug: 20096136
Change-Id: I78d0738428005fc19b3be85cc8f1db498043612f
(cherry picked from commit 2e36f2283f)
On normal Layers, we defer applying resize transactions until a buffer
of the correct size arrives. This breaks with sideband streams, because
buffers are not seen by SurfaceFlinger. This change applies
transactions immediately for Layers which have a sideband stream
attached to avoid that problem.
Bug: 20428254
Change-Id: I379d8aaef460d467cdf8432764b4a504928fb65a
(cherry picked from commit c300b8b506536e1bf94ffd8a3b75d46e776923e0)
Passes the surface damage from the incoming SurfaceFlingerConsumer
BufferQueue down to the hardware composer HAL interface, if the
HWC version number is 1.5 or greater.
Bug: 11239309
Change-Id: Ic4305210593874a8d6deba3319055b2b8c57e926
Switches all uses of IGraphicBufferConsumer::BufferItem (and
BufferQueue::BufferItem) to the BufferItem in libgui. Depends on
frameworks/native I699ed0a6837076867ca756b28d1ffb2238f7a0d9.
Cherry pick of I187b3a7d05196b6289596afac8fb9a9d4aebff76
Change-Id: I5bc79fb96b6cba6021af64b20890967aa3b7fcbf
- 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
Cherry pick of I070bd2e7c56506055c419004c29e2e3feac725df
Change-Id: I461952389c18051176c6b75e664f20ad369f5760
Ensure that the adjusted transparent region is within
the display bounds by clamping after the transformation
is applied and clean up transform's inverse function.
Bug: 18452546
Change-Id: Ia473e483ee8374177bcb84d8192eb1f0e86f022a
Currently, SurfaceFlinger is very dumb about how it handles buffer
updates at less than 60fps. If there is a new frame pending, but its
timestamp says not to present it until later SurfaceFlinger will wake
up every vsync until it is time to present it. Even worse, if
SurfaceFlinger has woken up but nothing has changed, it still goes
through the entire composition process.
This change (mostly) fixes that inefficiency. SurfaceFlinger will
still wake up every refresh period while there is a new frame
pending, but if there is no work to do, it will almost immediately go
back to sleep.
Bug: 18111837
Change-Id: I7825bacd37f40bf26edcc6a5e0f051dce45291fb
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
We normally recompute layer visibility when a layer gets its first
buffer; before then it's treated as invisible. Sideband layers never
get a buffer (as far as SurfaceFlinger knows), so never became
visible. Now we also recompute visibility when a layer gets a new
sideband stream.
Bug: 17752511
Change-Id: I84e150f196eb2eb7bcd2616248e5e3fa73624809
If available, surfaceflinger will use the hwc setCursorPositionAsync()
api to change the position of supported cursor layers outside of
the usual prepare/set loop.
Change-Id: Ib3fc5c0c390b3489ddbba202379840a1d2748917
Bug: 15116722
- Adds a sticky transform field that can be set from a
SurfaceFlinger client Surface. This transform is
added to any transform applied to the Surface.
Change-Id: Idaa4311dfd027b2d2b8ea5e2c6cba2da5779d753
It turns out that there's no reason to have both I* and Bn* versions
of the createBufferQueue method, so I removed the Bn* version.
Change-Id: I66aeb09e10458ae540ddf1f38d2d0154ea8f315b
- Notify a listener when sideband stream is set
- Mark a layer as visible when sideband stream is set, even though
no buffer is queued.
Change-Id: I9652bf530f2b5ce331533ec1bb3b10a815ca191c
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
Add the ability to ignore layers' transformation matrices during
screenshot capture, which will allow the window manager to capture
unrotated images for recents during the device rotation animation.
Bug: 11805195
Change-Id: I854d87bc84ca06ef9a054a454af1c080ee66fbb8
Moves the "opaque layer" from Layer to Layer::State. This allows
it to be updated as part of a transaction.
Bug 12387406
Change-Id: I0a114ce6adf77cd12fb08f96e0691b76c475768d
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 is an attempt at improving the experience of
users with color vision impairement.
At this time this feature can only be enabled for
debugging:
adb shell service call SurfaceFlinger 1014 i32 PARAM
with PARAM:
0 : disabled
1 : protanomaly/protanopia simulation
2 : deuteranomaly/deuteranopia simulation
3 : tritanopia/tritanomaly simulation
11, 12, 13: same as above w/ attempted correction/enhancement
The enhancement algorithm tries to spread the "error"
such that tones that would otherwise appear similar can be
distinguished.
Bug: 9465644
Change-Id: I860f7eed0cb81f54ef9cf24ad78155b6395ade48
specifically when the display size and the screenshot window
size didn't match, the buffer would be rejected.
We simply fix this by setting the scalling mode to
"SCALE_TO_WINDOW".
Bug: 9992306
Change-Id: Ib821767899af330bb70d3cbbfa7d41b02794a075
If a layer is not cropped but its bounds are outside of the
viewport (i.e.: clipped), the crop rectangle passed to
hw composer would be invalid because it started invalid
in the first place (to indicate "no crop").
Bug: 10410944
Change-Id: I4ae4d49a1adef0be7fa4304ecf84b1a5b7d03fe0
the main reason for doing this is so that we can have
access to informations about a texture (like its dimension)
close to where we generate and use shaders in ES 2.0.
Previously, there wasn't any way to get to a texture's size
from a RenderEngine implementation.
Bug: 8679321
Change-Id: I388b338a70d07e3e8177dde248710ea1e4c82dff
the Mesh object can be part of each Layer (at least currently).
also reworked the Mesh code a bit to make it easier to access
the vertex data.
Change-Id: I0490851ba898f0aa2e55b62958dcd8bdb535e98b
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
Dan Stoza