This change allows SurfaceFlinger to run at a different vsync phase offset from
that used by external listeners.
Bug: 11175503
Change-Id: I561c53a5659fa6dc1e3e4ae30340f3c1a6adceb4
This change adds a new thread for calling HWComposer's eventControl
asynchronously. The DispSync-based vsync approach ends up enabling and
disabling HWComposer's vsync callbacks at arbitrary times, and some HWComposer
implementations do not have these calls optimized.
Bug: 11175503
Change-Id: I719be82bd200b391c61d40863b991c7b59acdfd6
The screen capture code wasn't waiting for the render to finish,
so sometimes you'd see an empty or partial image.
Bug 11131777
Change-Id: Ic64087322ce3bb15bb5f4fb1eb07579880fe6197
This change adds the DispSync class, which models the hardware vsync event
times to allow vsync event callbacks to be done at an arbitrary phase offset
from the hardware vsync. This can be used to reduce the minimum latency from
Choreographer wake-up to on-screen image presentation.
Bug: 10624956
Change-Id: I8c7a54ceacaa4d709726ed97b0dcae4093a7bdcf
When there are no window layers for a display, SurfaceFlinger clears
the undefined region using GLES. Some of the places that check for
GLES composition weren't considering this special case, in particular:
- We were skipping the eglSwapBuffers() on these frames.
- We were putting VirtualDisplaySurface in HWC-only composition mode.
This change centralizes the logic for this special case.
Bug: 10957068
Change-Id: I2deaf2ed101e8ea76708862a6bb67751b6078794
This fixes two bugs introduced by
Change-Id: Ia8cc084c02a0e3de910def024da8a08d02bbd89d
(a) There is no invalid EGLConfig value, in particular zero is valid.
Checking return values of eglGetConfigs and eglChooseConfig is the
only way to determine success.
(b) The "simple" EGLConfig query used as the emulator fallback should
not include EGL_RECORDABLE; the emulator doesn't have it.
Bug: 10935622
Change-Id: Ib798a24e7cf06a679811c46eaa45d39174a715ec
Explicitly selects an ES 2.0 config first, then an ES 1.x config,
before attempting the fallback path for the emulator.
Bug: 10820214
Change-Id: Ia8cc084c02a0e3de910def024da8a08d02bbd89d
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
SF can spawn threads (indirectly) during initialization
and we want those to be spawned at URGENT_DISPLAY_PRIORITY
(in theory they should set their own, but some code lives
in vendor libraries and doesn't).
Bug: 10430209
Change-Id: I5b3a8f979297de287614c8eafd8267bef1176e4b
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
We weren't dequeing and setting the output buffer until just before
set(). This didn't allow HWC to make decisions in prepare() based on
the output buffer format, dimensions, etc.
Now we dequeue the output buffer at the beginning of the composition
loop and provide it to HWC in prepare. In GLES-only rendering, we may
have to cancel the buffer and acquire a new one if GLES requests a
buffer with properties different than the one we already dequeued.
Bug: 10365313
Change-Id: I96b4b0a851920e4334ef05080d58097d46467ab8
it used to spawn its own thread and return the main thread
to the binder thread pool -- this was confusing the naming
of things in the kernel.
Bug: 10331839
Change-Id: I2d13a6d73409a38109300fcbe6a04b4c41cb5d00
we need too allow this case so that things like the rotation
animation can work.
with this change we only permit these screenshot if the
destination is SurfaceFlinger itself.
Bug: 10235036
Change-Id: I66fea5391e52b0d7f17f25827572b236f2d9eb71
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
A recent change to screencapture to have the call to
IGraphicBufferProducer happen on the incoming binder
thread didn't set the result so the result was always
returned as NO_ERROR.
This made screencap fail on some devices (e.g. Wolfie)
which relies on some kind of fallback mechanism to
generate the screencap but the fallback mechanism
doesn't get triggered because the error isn't returned.
Bug: 9989385
Change-Id: I2aee91ea1034869fcbb0f49b9a0087c3cff43bbe
Signed-off-by: Mike J. Chen <mjchen@google.com>
The previous implementation assumed that the HWC could read and write
the same buffer on frames that involved both GLES and HWC composition.
It turns out some hardware can't do this. The new implementation
maintains a scratch buffer pool to use on these mixed frames, but on
GLES-only or HWC-only frames still does composition directly into the
output buffer.
Bug: 8384764
Change-Id: I7a3addb34fad9bfcbdabbb8b635083e10223df69
because surfaceflinger handles screenshot in a different
thread from the binder thread that requested it and because
the IGraphicBufferProducer is a synchronous interface
calling back into the system server; it is possible for
the latter to run out of binder threads (b/c it holds
a lock while calling into SF).
The solution is to make sure all calls on IGraphicBufferProducer
happen on the incoming binder thread. We achieve this by creating
a IGBP wrapper which is given to the screenshot code.
Bug: 8734824
Change-Id: I2be85660d9dc65d239d68f6d3ab3c973c13b34cc
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
- most methods on Layer didn't need to be virtual
- more consistency in naming drawing/current state
Change-Id: Ieb7b4951b40fc673b807994ed21ae4aea7281068
generally the last reference to a Layer is released in commitTransaction()
with mStateLock held. Layer itself only holds weak references to Client,
however, ~Layer() briefly promotes this weak reference -- during that time
the all other strong references to that Client go away, ~Layer is left with
the last one... then hell breaks loose as ~Client is called, which in turn
needs to acquire mStateLock.
We fix this by holding a temporary copy of the drawing state during
the transaction so that the side-effects of copying the current
state into the drawing state are seen only after mStateLock has
been released.
Bug: 9106453
Change-Id: Ic5348ac12283500ead87286a37565e8da35f1db2
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
If an invalid display device is detected during surface composition
(e.g., a simulated secondary display is removed), abort the
composition.
Change-Id: Ia6afb2e287882d8ae0614eb25463d3f85b687adf
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 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