This change adds support for displays that are not allowed to display surfaces
with the eSecure flag set. All non-virtual displays are considered secure,
while virtual displays have their secure-ness specified at creation time.
Bug: 7368436
Change-Id: I81ad535d2d1e5a7ff78269017e85b111f0098500
Some of the code in latchBuffer was calling invalidateHwcGeometry,
but that didn't cause the SurfaceFlinger visible region code to
re-evaluate the layer's visibility. Set the recomputeVisibleRegions
"out" parameter instead.
Bug 7235797
Change-Id: If6ba33fbd1a594cd64cc5253aebf752d6ceda1c9
This change makes updateTexImage default to performing the necessary
synchronization and adds an argument for SurfaceFlinger to disable that
synchronization so that it can be performed lazily.
Change-Id: I7c20923cc786634126fbf7021c9d2541aa77be5d
Bug: 6991805
The hints were being set a little too late, so the pre-rotation stuff
wasn't quite working.
Bug 7054997
Change-Id: Id8d5c626db7a76f768ba762a145b315878ee08e6
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 adds a compile-option to use eglWaitSyncANDROID to ensure that
texturing operations that access the current buffer of a SurfaceTexture do not
occur until the buffer is completely written. It also moves this
synchronization into a new SurfaceTexture method called doGLFenceWait and
changes SurfaceFlinger's Layer class to use that method rather than performing
its own wait on the fence.
Change-Id: I70afa88086ca7ff49a80e3cd03d423767db7cb88
we used to have a visibleRegion object per layer, but now
it's per screen; so at somepoint the code got changed to
calculate the per-screen visible region on the stack and that's
what got passed to HWC.
we're now setting the visibleRegionScreen at each frame and
freeing at after the HWC set() call. We use the underlaying
SharedBuffer so that in most cases we don't have to allocate,
free or copy memory around.
Bug: 7089478
Change-Id: I24fa556c76613a225d9fe7a6c6b727bb476144d8
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
DisplayDevices are now keyed of the wp<IBinder> the client uses.
DisplayID has now become DisplayType which is just used to identify
physical displays (as opposed to virtual displays such as wifi displays).
Change-Id: I0c5968f2c902dcd699a7e0afacf833ff070c12ea
it's safer this way because this object owns an
EGLSurface which cannot be easily reference-counted.
it also gives us the ability to sub-class it, which
we might want to do soon.
Change-Id: I07358bb052dc5a13b4f2196b2c2b6e6e94c4bb4f
- fix typo drawForSreenshot misspelled
- get rid of DisplayDeviceBase
- removed unused or unneeded code
- always pass a DisplayDevice to Layer methods that are called
on a per-display basis (to make it clear that this could be
called more than once per composition).
Change-Id: Id948b7e09fe5c06db0e42d40d6ed75dd095c7f44
mostly refactored SurfaceFlinger.h, but also removed dead code.
cleaned-up a few includes as well.
Change-Id: Ib15f4ffe567912b61ee98aa076c6a283b72811b5
- remove dependency on cached state in validateVisibility
- get rid of mVertices and mTransformedBounds
- get rid of validateVisibility
- get rid of unlockPageFlip
- handleTransaction now returns a dirty region
- computevisibileregion now uses window-manager space
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
HWComposer must abstract the HWC HAL entirely, so that the
HAL can continue to evolve (and break binary compatibility)
without breaking SurfaceFlinger. The HWC data structure had
leaked outside of HWComposer, this is now fixed.
We now have an abstract interface that provide all the
needed functionality, HWCompose provides concrete
implementations of it based on the the HWC version.
Change-Id: I40c4676dc986b682ede5520a1c60efe64037b0bb
this would happen when a resize was pending (ie: we have received
and processed a resize transaction but have not received a buffer
with the right size) and a new transaction came in that didn't
involve a resize, for instance a translate-only transaction.
in this case, we would incorrectly update the drawing state
with the pending size, eventhough we still don't have a buffer
for it.
the solution is quite simple, we never allow the size to propagate
from current to drawing state during the regular transaction processing
(unless we are in fixed-size mode -- meaning we don't need to have
a matching size buffer), this propagation happens later once we
receive the buffer.
Bug: 6624163
Change-Id: I11a97e4b88a7f3a0571ddcfe99c86cb04ce01a4d
this would happen when a window started with size A, was
resized to B and immediately resized to A. In this situation
the erquested and active size would be the same, and SF
would think a transaction wasn't needed.
we fix this by always comparing the requested sizes.
Also, make sure to set mRefreshPending once we're sure
we have succesfully called updateTexImage().
Bug: 6580962
Change-Id: I2c48b4df7f05fd35c9e1d2dd82095b0f3d5a0b6a
this bug introduced recently would happen when the very first
buffer of a surface was rejected for not having the right size
Bug: 6577035
Change-Id: I9fabf20006019f2a6c308be7c7f5c05bdcfd5014
SurfaceFlinger is using this new feature to reject buffers that
don't have the right size.
Bug: 6498869
Change-Id: I8a7250a47db6c082a357b703feb3b9d0fc8d3443
here we just shuffle a bit the code inside lockPageFlip(),
we move the code that handles the buffer size closer to the call
to updateTexImage(). no functionality change.
Change-Id: Ie3193cd86cd32cf3c89532449fd747d145ca0ab6
use a flag instead of pre-committing the "requested" state
to prevent propagation or "requested" to "active", which makes
things a lot clearer when reading the code.
also avoid going through the "resized" code-path when requested
size is equal to "active" size.
Bug: 6498869
Change-Id: I24f893ba0ec5ca06aac5b8da9818989ae7ce4005
The crop is now handled like a resize, it's latched only when we
receive a new buffer in the case we have a resize in the same
transaction.
Bug: 6498869
Change-Id: I9f3cbbe08fb19443899461ec441c714748a4fd1a
This change removes some visible region recomputation that was needed to handle
the SCALING_MODE_FREEZE cropping. We've changed things to use a window crop
from the WindowManager instead, so this is no longer needed.
Bug: 6299171
Change-Id: I32fbc2b689c985837126d8ba3d9a91e79613ffbf
This change adds a crop rectangle specified in window coordinates to the layer
state. The all window pixels outside this crop rectangle are treated as though
they were fully transparent. This change also adds the plumbing necessary for
WindowManager to set that crop.
Change-Id: I582bc445dc8c97d4c943d4db8d582a6ef5a66081
This change makes a change in the crop, scaling mode, transform, or buffer
dimensions trigger a recomputation of the visible regions of a window. With
the new cropping behavior for SCALING_MODE_FREEZE all of these can now affect
the visible region.
Bug: 6470541
Change-Id: I1904e47efbd708e28bf189f637d24dbef65cd41e
This change adss support for applying a buffer crop to layers with the
SCALING_MODE_FREEZE scaling mode. These layers do not scale the image, but
rather treat all pixels outside the crop rectangle as fully transparent.
Change-Id: I762518e56a37aef7747f9b581df2f2589b232c49
Bug: 6299171
This change makes SurfaceFlinger set the filtering-enable on each layer's
SurfaceTexture before querying the texture matrix to use for GLES composition.
Change-Id: I40c3defd73ebf96e3cabb3bfdb1fc97f2036753a
this could happen after an orientation change. basically
we need to triger a geometry-changed when the very first buffer
is received
Change-Id: I097e411fd6612c18725737cffccdbf6b2af3511c
re-add support for pixelformats L_8, LA_88 and RGB_332 in libui
for backward compatibility.
This may or may not fix 6058926
Bug: 6049685
Change-Id: Ic1b8b4cc994522f7fe664da64c0ef76b98bc6d53
we're seeing UI freezes when window updates and
composition are separated. for now we workaround this
by always doing a composition after window updates on
vsync. triple buffering is reenabled for performance.
Change-Id: I693d705000b7452489bb0b4918fbeadb9879315c
with this changes, SF transactions are handled as soon as possible
but do not trigger updates. the update is delayed until the next
vsync.
this allows us to work much better without requiring triple-buffering.
Change-Id: I1fa10794d0cf742129f0877698b7b1e1f2ec7401
--latency-clear [name]
clears the latency data for the specified layer or for
all layers if none is specified
--list
prints the list of all layers regardless of their visibility
Change-Id: I7c07ae020f838c173b98ee50f3fb3e93da78acbb
It is now possible to say:
dumpsys SurfaceFlinger --latency
to print latency information about all windows
dumpsys SurfaceFlinger --latency window-name
to print the latency stats of the specified window
for instance: dumpsys SurfaceFlinger --latency SurfaceView
The data consists of one line containing global stats, followed by
128 lines of tab separated timestamps in nanosecond.
The first line currently contains the refresh period in nanosecond.
Each 128 following line contains 3 timestamps, of respectively
the app draw time, the vsync timestamp just prior the call to set and
the timestamp of the call to set.
Change-Id: Ib6b6da1d7e2e6ba49c282bdbc0b56a7dc203343a
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Make sure to call compositionComplete() after rendering into a FBO.
Bug: 5446982, 5467587, 5466259
Change-Id: I5d8a1b4c327f9973d950cd4f4c0bca7f62825cd4
when taking a screenshot, in particular, we could end up
with stale GL state when drawing LayerDim which resulted
in incortect rendering.
Bug: 5467587
Change-Id: Id9fbed2843481d31063620f3662b364c7e3ac781
This change removes the dead code from SurfaceFlinger that resulted from
disabling support for freezing the display.
Change-Id: I4e5ff00c94b4c7a79af2f65c9850c135210068ed
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Bug: 5446982
Change-Id: I7814aff2380e7e146937f2b641907be2a30c76cc
This change modifies SurfaceFlinger's screenshot behavior when a layer
with a protected buffer is visible. The previous behavior was to simply
fail the screenshot. The new behavior is to render the screenshot using
a placeholder texture where the protected buffer would have been.
Change-Id: I5e50cb2f3b31b2ea81cfe291c9b4a42e9ee71874
This change makes SurfaceFlinger update a SurfaceTextureLayer's default
buffer size in response to a window resize even if the Layer is in fixed
size mode.
Change-Id: I3871c8f19a045d03904d1284390cad7659be71ff
Bug: 5366426
This change fixes the transform hint to use only the global display
transform rather than incorporating the transient layer-specific
transform used during animations.
Bug: 5366891
Change-Id: I5408dcd3f4771d010953e8a696a484c835bfe81e
This change fixes an issue where Layer::isOpaque was being called in
lockPageFlip to get the opaqueness for the new buffer before
mActiveBuffer was updated.
Bug: 5321313
Change-Id: Ibb5d7d3f4e9a2b1448e117a484a0d9f9ca5fc9de
This change fixes an issue where Layer::isOpaque was being called in
lockPageFlip to get the opaqueness for the new buffer before
mActiveBuffer was updated.
Bug: 5321313
Change-Id: Ibb5d7d3f4e9a2b1448e117a484a0d9f9ca5fc9de
We were not updating the h/w composer state when the buffer size
changed.
We also didn't update the h/w composer state when the transformation
matrix changed (which is related to the above issue, since it would
probably change when the buffer size changes).
Also moved updating the crop to setGeometry(), since we decided
that the "crop" change requires the GEOMETRY_CHANGED flag (ie:
not need to do this every frame)
Bug: 5238473
Change-Id: Ia7b47e145b48581b568d89d9aa2c14ff778be862
This change makes SurfaceFlinger always use the
GRALLOC_USAGE_HW_COMPOSER usage bit when allocating buffers that may be
passed to the HWComposer.
Change-Id: I70362a8ede2b359fb2046853f85149d597465817
we were using the "orientation" value instead of the
real transform, which may contain arbitrary rotations for
instance, and in some case ended up with a final "orientation"
that looked valid, but wasn't.
this fixes a problem on devices with a h/w composer hal where
the rotation animation looked weird.
Change-Id: I4be8a2a1bde49c33456fcf5c8d87ab515c216763
This change fixes the NATIVE_WINDOW_QUEUES_TO_WINDOW_COMPOSER query of
Surface and SurfaceTextureClient. Surface now uses the inherited
SurfaceTextureClient implementation of this query. SurfaceTextureClient
now queries SurfaceFlinger to determine whether buffers that are queued
to its ISurfaceTexture will be sent to SurfaceFlinger (as opposed to
some other process).
Change-Id: Iff187e72f30d454229f07f896b438198978270a8
a wrong orientation would be briefly shown when
rotation the screen. this happened when the window manager
set a custom transformation and the h/w composer was used.
the custom transformation was applied twice in that case.
Bug: 5037522
Change-Id: Ic1f87b63cd843f4475e4265d1624463825d775c4
This change makes the Layer::onRemoved method call
SurfaceTextures::abandon on the layer's SurfaceTexture. This will cause
all client-initiated operations on the SurfaceTexture to fail. In
particular, this will result in an error on the client side, rather than
a deadlock when removing a layer that used a SurfaceTexture in
synchronous mode.
Change-Id: I14014d00369f29560a21b606831edee432bb8867
Bug: 5020874
This change fixes a bug where the window visibility would be computed
before any buffers were available, causing the window to be treated as
non-opaque. When the first buffer arrived, if both mCurrentOpacity and
the opacity determined by the buffer's format were 'opaque', a
recomputation of the opacity would not be done, and the window would
continue to be treated as non-opaque. SurfaceFlinger could then
unnecessarily draw fully occluded layers.
Change-Id: I2b95da2f4b50e68d50fc5afd8b772e26e62f58d6
Bug: 5057122
if the state transform didn't preserve rectangles, we
would still try to use h/w composer hal using the bounds
of the transformed rect, which isn't correct.
now we correctly fall back to composition.
Change-Id: Iff78f4339ece415d4987e95a5717b04934d370ab
This change alters the conditions under which the onFrameAvailable
callback gets called by the C++ SurfaceTexture class. The new behavior
is to call the callback whenever a frame gets queued that will be
visible to the buffer consumer. This means that buffers queued in
synchronous mode always trigger the callback, as those buffers will
remain pending until they are consumed. Buffers queued in asynchronous
mode will only trigger the callback if there was not previously an
unconsumed buffer pending.
The new behavior means that a consumer should perform a draw operation
exactly once for every onFrameAvailable call that it recieves. This
change also modifies SurfaceFlinger and the SurfaceTexture JNI to
support of the new behavior.
Change-Id: I8b2c6e00961d3d58b11c6af50b555b6e4c5f5b40
Add the concept of synchronous dequeueBuffer in SurfaceTexture
Implement {Surface|SurfaceTextureClient}::setSwapInterval()
Add SurfaceTexture logging
fix onFrameAvailable
This change makes SurfaceFlinger unfreeze a window if it ever gets a
buffer that is fixed-size. Normally the window would not be frozen if
its in fixed-size mode, but if the window was frozen before entering
fixed-size mode then it should be unfrozen.
Change-Id: I6bc822d4b02ae51fa8914c1f60f5d24b2002b38d
