To keep the code readable now that we have four different texenv
configurations, this change separates the decisions about what
configuration to use from the GL calls to set up the configuration.
Bug: 8963244
Change-Id: Ia07a306a7809ba8f93493d0160ccbd509e948581
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
If an invalid display device is detected during surface composition
(e.g., a simulated secondary display is removed), abort the
composition.
Change-Id: Ia6afb2e287882d8ae0614eb25463d3f85b687adf
until now it was only used to discard a layer entirely.
we're now reducing the size of the layer if it is still
visible, if possible.
this works for instance when a surfaceView is used and
only the menu bar is displayed over it.
Change-Id: I3f5527c5cd1e69ecc968272c8948f1513ada8c55
this allows us to render into a buffer with a
pixelformat of our own choice; this is much faster
on all platform.
Bug: 8582615
Change-Id: I61298fc8e43fa6f92044c5123955cb5c7897dab7
colorize a bit the output of dumpsys SurfaceFlinger to
make it easier to read. Right now it will bold the
title of each section and use green for the name of
each layer.
Change-Id: I0d9f18d115401cb45109d244ef3a278481f68cc6
this mimics the code we used for the size. basically we need to
also update the "current state" because it gets copied to the
"drawing state" when a transaction occurs, and it would
"undo" our change.
Bug: 8511430
Bug: 8581533
Change-Id: I08c02abbf21b7f168f7124cd14ee717d7d3d502c
this affects devices that need a glReadPixels(). We use
a FBO instead of a GlConsumer as an intermediate render target, this
saves 2 calls to eglMakeCurrent().
On Galaxy Nexus this allows us to go from ~135ms to ~35ms for
recent's screenshots.
Bug: 8582615
Change-Id: I6b25291ecc235f1927579bbb2db3c731e985c6e8
When the screen is turned off, the current stack is set to -1. This causes
logic in iSurfaceFlinger's handleTransactionLocked() function to fail to
match the current stack, and the latest orientation is not set into the
layer. This causes BufferQueue, later, to potentially set an obsolete
transformHint on a created surface (such as in the case with ImageWallpaper's
Egl surface, in the bug below).
The fix is to note this situation and use a default value for the DisplayDevice,
which should have the current orientation information.
Issue #8508397 ImageWallpaper sometimes rendered in wrong orientation causing a ~30-40% drop in graphics performance
Change-Id: Ibae15d73b289a8343c67f4f6bb77fdf11dd95ee7
SF transactions were always handled on VSYNC which allowed
the screenshot to sneak-in between closing the transaction
and vsync (before it's latched), resulting in a screenshot
with the previous state.
we now always force transactions to happen immediately
before screenhots.
Bug: 7552304
Change-Id: I0afc86b7e8366173daff5b9988bbb4d2a0f43860
HWComposer queries the HWC for dimensions of physical displays, but
can't do that for virtual displays. The dimensions are used to set the
display frame of the framebuffer target layer passed to HWC, and
implicitly the dimensions of the virtual display.
Bug: 8316155
Change-Id: I9cbd2530d2fa878f86128a1472def520b5d694a5
since the transparent region hint really depends on the
content of the window containing the SurfaceView
(it's calculated by the view hierarchy based on
overlapping views), it makes sense to latch it only when
the content of the window (the app) changes.
This should help fixing drawing artifacts when changing the
layout of a window containing a SurfaceView.
Bug: 8511430
Change-Id: Ic3aa668495293cb4d82a2cd7dcf3b6a337287678
We now detect at runtime which sync features to use, which
allows us to remove a lot of the compile-time configuration
options. There is still one option though, to disable
KHR_fence_sync on some devices (which are more efficient
without it).
- added a backdoor to get the vendor's EGL strings
the new logic is:
- use always ANDROID_native_fence_sync if available
- fallback to KHR_fence_sync if available and not disabled
by the compile-time option
- use KHR_wait_sync if available and either of the above is
enabled
Change-Id: I9c4b49d9ff1151faf902cc93bd53ea5f205aaabf
DisplayDevices can be released when DisplayManager removes them from
the display list, or (for virtual displays) when the surface is set to
NULL. We were only cleaning up HWC resources associated with the
display in the first case.
Bug: 8384764
Change-Id: Id3d226dd7178fbe6d0a2ac4e2660b864ee073de3
If we're using a HWC that doesn't support virtual displays, or we have
more virtual displays than HWC supports concurrently, the
VirtualDisplaySurface should simply be a passthrough from source
(GLES) to sink.
This change also tries to distinguish between display types and HWC
display IDs a little better, though there's more to do here. Probably
needs a higher-level rethink; it's too error-prone now.
Bug: 8446838
Change-Id: I708d2cf262ec30177042304f174ca5b8da701df1
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
some drivers don't support this yet, so we use a system
property to enable the glReadPixels "workaround" for them:
ro.bq.gpu_to_cpu_unsupported=1
Change-Id: I74d6a3a8f0cee8d5a507b72c760cf247e39195e0
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
We're not using IMemoryHeap as a transport anymore,
instead we're providing a CpuConsumer and use the
IGraphicBufferProducer version of the screenshot API.
However, some GPU drivers don't support properly
a GPU to CPU path, to work around this, we use a
temporary BufferQueue on the server side for the
GL rendering, and we use glReadPixels into the
CpuConsumer (we're now using a CPU to CPU path
which is always supported).
Currently this "wrapping" is always performed,
but it can be bypassed on devices that support
the GPU to CPU path.
This also addresses a DoS attack vector on
SurfaceFlinger, where an application could
consume all of SF's filedescriptors by creating
a lot of screenshots in a row.
Bug: 8390553
Change-Id: I9e81514c2a7711b9bb393f74305be7d2abe08f1c
