this is the first step to add support for GLES 2.x, this
change breaks the dependency of SF on GLES 1.x by moving
all operation into their own class.
Bug: 8679321
Change-Id: I0d2741eca2cefe67dfd9cf837cac10c4d126928b
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
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
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
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
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
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
the purgatory list wasn't needed anymore; in fact it had no effect as
buffer life-time management is now handled by the BufferQueue.
For QueuesToWindowComposer we keep a list of wp<> on the IBinder
for IGraphicBufferProducers we hand over to clients so we can
easily check if an IGraphicBufferProducer is ours. We clean-up the
list when our IGraphicBufferProducer are destroyed.
Bug: 8349142
Change-Id: I1aa06652ade8c72d0004a3f5e6c3d6e8a82fc2ae
ISurface was only used to get the IGraphicBufferProducer from
a Layer. It's now replaced by a BBinder subclass / IBinder and
is only used as a handle to the surface, to both refer to it
and manage its life-time.
Also cleaned-up a bit the ISurfaceComposer interface and
"create layer" code path.
Change-Id: I68d0e02d57b862cffb31d5168c3bc10cea0906eb
The functionality of LayerBase and Layer is folded
into Layer. There wasn't a need for this abstraction
anymore.
Change-Id: I66511c08cc3d89009ba4deabf47e26cd4cfeaefb
- SurfaceFlinger now supports to take a screenshot
directly into an IGraphicBufferProducer
- reimplement the IMemoryHeap screenshot on top
of the above
- reimplement LayerScreenshot such that its
BufferQueue is directly used as the destination
of the screenshot. LayerScreenshot is now a thin
wrapper around Layer
Bug: 6940974
Change-Id: I69a2096b44b91acbb99eba16f83a9c78d94e0d10
This change makes the 'dumpsys SurfaceFlinger --latency' command with no extra
args dump the frame timestamp data for the most recent frames that
SurfaceFlinger generated that included window animation transaction changes.
Change-Id: I8bded1ea08a4cddefef0aa955401052bb9107c90
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
For hotpluggable builtin displays (currently just HDMI), create the
display device IBinder token when the display is connected and destroy
it when the display is disconnected. Previously we created the tokens
at startup and never changed them. This made it so that when comparing
current and drawing state, we couldn't tell whether a display had been
disconnected and reconnected.
Bug: 7491120
Change-Id: I23b77037dc0f548d549abf580339edd0e3c626e9
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
we were holding a reference (ie: pointer) to a sp<DisplayDevice>
while processing the message. Meanwhile the object itself could
go away and we would end up accessing a dead object.
the root cause of the problem is that we are accessing mDisplays[]
in a few places outside of the main thread.
Bug: 7352770
Change-Id: I89e35dd85fb30e9a6383eca9a0bbc7028363876c
This change adds a transaction flag for WindowManager to indicate that a
transaction is being used to animate windows around the screen. SurfaceFlinger
will not allow more than one of these transactions to be outstanding at a time
to prevent the animation "frames" from being dropped.
Bug: 7353840
Change-Id: I6488a6e0e1ed13d27356d2203c9dc766dc6b1759
when enabling/disabling vsync we now make sure to
not call into the HAL if the state wouldn't change.
Bug: 7274951
Change-Id: Ie24a6d68888a51b577acf9c2a973d85437cbacaf
This allows us to blank and unblank displays other than the built-in
display (e.g. HDMI).
Bug: 7240511
Change-Id: I89ea13f9e497be74c3e1231d0c62fb558e93e0f8
we now try first with EGL_FRAMEBUFFER_TARGET_ANDROID, and
pick the first config we find. Otherwise, we revert to
the old algorithm.
Bug: 7232584
Change-Id: I8d5c5a4ce48420832c2e2828718a8f53325effb0
This adds a line to the "dumpsys SurfaceFlinger" output that shows
build-time configuration values.
Example:
Build configuration: [sf HAS_CONTEXT_PRIORITY] [libui] \
[libgui USE_FENCE_SYNC]
Bug 7206633
Change-Id: Ibe1856b459d34a4be6ee83a4ebfd2807e6cc68a0
The Surface createDisplay() call takes a display name for debugging.
This change carries it through SurfaceFlinger and displays it in
the "dumpsys SurfaceFlinger" output.
Bug 7058158
Change-Id: I79f3474a8656ff1beb7b478e0dbf2c5de666118a
- decouple GL and main display initialization
- ensure that each "supported" display has its own FramebufferSurface
- onScreenAcquired/Released now takes a display
Change-Id: If34a05f3dea40f6c79db77f4dde283a2580daac4
we now make sure to take the blanked state of a display into
account when we build its list of visible layers, this ensures
that we won't call prepare/set with a non-empty list when the
display is blanked.
Possibly fixes 7075380, 7103553, 7130187, 7016215
Bug: 7075380
Change-Id: I9fdd2e73d1b7621eaeca3d4ac2ae60d9fb1b3631
- the library is dlopened from libsurfaceflinger
- the library built only when libnativehelper exists
Bug: 7089510
Change-Id: Ib3ea1029d7e8f6e055f4b759d0bf68f5123fa8a1
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
Use only display tokens in the API to refer to new displays.
Don't require the caller to specify the display when creating
a surface (since in general a surface could be shown on
any display).
This is intended to be a minimum change just to update the API.
Note that SurfaceFlinger still uses DisplayID in a few places
internally that might cause some features not to work properly
when there are multiple displays (LayerScreenshot, for example).
Change-Id: I3d91eec2da406eefd97bcd53655d403ad865a7e6
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
Change-Id: I0fa52e9e719c6e997c5725a7baf15d9718461b78
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
(This reverts an earlier revert.)
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
Change-Id: Idaa0d0b98ebb331a17d1b16774c6b05bfa1e8728
when multiple displays are connected, we ended-up having to
call eglMakeCurrent() twice per display due to a limitation
in EGL. this fixes that.
Change-Id: I11e4584df50f8c24bbecee74e37b28b3ee031d2f
fix a few bugs with external displays
- HWComposer doesn't really handle multiple displays yet
so there is a lot of ugliness there
- We also need to make sure that external displays are not
blanked by default
- due to some EGL limitations surfaces being swapped need
to be current
Change-Id: I82bff05b43bcebd8da863c7c76b4edbc3bc223a9
