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
Without that lock, there is a chance of race condition
where while composing a specific index, requestBuf with
the same index can be executed and touch the
same data that is being used in initEglImage.
(e.g. dirty flag in texture)
This change makes Layer skip its cleanup of its old shared memory region
when the UserClient object that owned the memory has been freed.
Bug: 3429357
Change-Id: I9e4d8eb190f6914dc043674b9bb8dd28e959901b
a memory corruption happned when the buffer pool was resized
(like when playing a video or using camera) and there was
no current active buffer. In this case, the faulty code
would index into an array at position -1 which corrupted
24 bytes of data.
also improved region validation code (ifdef'ed out by default)
Bug: 4093196
Change-Id: I915c581d131148959d720e00e3892e9186ab733d
mFormat is not initialized with any value in Layer constructor, causing
a call to requestFormat() with no explicit format specified to fallback to
some uninitialized value. Such invalid path actually detected by valgrind.
Change-Id: Ib7faabcd61eaa26fb0ae7a9a486d9e258ba31b63
This change makes SurfaceFlinger treat layers for which the active
buffer has the GRALLOC_USAGE_PROTECTED bit set as if they have the
'secure' flag set.
Change-Id: Ic60b6513a63e4bb92ec6ce9fd12fd39b4ba5f674
Bug: 4081304
SF kept a strong reference to ISurface until the
window manager removed the surface from the screen.
This fell appart when running standalone tests, that is
when the window manager wasn't involved.
When the window manager is around, it would clean-up surfaces
even when an application died.
with this change, SF is able to do its own cleanup without
relying on the window manager.
the change is very simple, we simply don't keep a reference
to ISurface and make sure no more than one of them can
be created.
Change-Id: I61f2d7473bf8d4aa651549a846c34cdbb0d0c85a
Check requested format for device-specific formats, and assume (as
documented in libhardware/include/hardware/hardware.h) this is opaque
layer so no blending is necessary.
Bug: 3215931
Change-Id: Ib4dff8060ac522d201ff1e74807ac340c17d3fa7
We were still destroying an ANativeWindow's buffer pretty soon
after it was removed from the window manager. This time
we really wait for the ISurace to go away.
Change-Id: I329273fedaeef76ee92836f6180c2c3808389330
Generally we never want to lock a buffer for write access if it is at
the "head" on the surfaceflinger side. The only exception (1) is when
the buffer is not currently in use AND there is at least one queued
buffer -- in which case, SurfaceFlinger will never use said buffer
anymore, because on the next composition around, it will be able to
retire the first queued buffer.
The logic above relies on SurfaceFlinger always retiring
and locking a buffer before composition -- unfortunately this
didn't happen during a screenshot.
This could leave us in a situation where a buffer is locked by the
application for write, and used by SurfaceFlinger for texturing,
causing a hang.
Here, we fix this issue by never assuming the exception (1), it was
intended as an optimization allowing ANativeWindow::lockBuffer() to
return sooner and was justified when most of SF composition was
done in software. The actual buffer locking is now ensured by
gralloc. We could have handled screenshots in a similar way to
a regular composition, but it could have caused glitches on screen,
essentially, taking a screenshot could cause to skip a frame.
now that we removed the notion of a "inUse" buffer in surfaceflinger
a lot of code can be simplified / removed.
noteworthy, the whole concept of "unlockClient" wrt. "compositionComplete"
is also gone.
now that we removed the notion of a "inUse" buffer in surfaceflinger
a lot of code can be simplified / removed.
noteworthy, the whole concept of "unlockClient" wrt. "compositionComplete"
is also gone.
Change-Id: I210413d4c8c0998dae05c8620ebfc895d3e6233d
if a surface's buffers are reallocated, the current active buffer will
end-up pointing on one of these until a new buffer is retired.
we're now keeping a reference to the actual buffer until we retire a
new one.
Change-Id: Ib1703947e7a0340694d846e0962576318863b935
there was an issue were in some situation SF would call prepare() on hwc
with a NULL handle and never call prepare again.
in this situation, we onw set the SKIP flag to make sure that hwc
won't process this layer and as soon as we receive our first buffer we
trigger a recompute of the visible regions which will end-up calling
prepare() again.
Change-Id: I6b400b2df79712408b9315a9859290c7fcb1609e
There was a leak of Surface tokens when a surface was detached from a UserClient.
We now always detach a surface from its client before attaching to the new one,
this guarantees that its token is freed.
Change-Id: Icfad0b16286ed58155bdfafdf36ab161440aa485
This is a poor's man precursor to the h/w composer HAL.
Basically we detect when a window is full screen and in
that case we bypass surfaceflinger's composition step, which
yields to much improved performance.
Change-Id: Ie03796ae81a1c951949b771c9323044b980cb347
mFixedSize was never set, this bug was introduced during some "cleanup", in
practice this could cause some issues when a fixed-size buffer was used and
the window was resized.
Layer::drawForSreenShot() had a typo that had no effect.
mFixedSize was used to determine if filtering was needed, which was a bit too
conservative and created a dependency between filtering and "fixed size" states
which should exist.
Now we enable filtering based on the size of the buffer vs. the size of the layer.
Change-Id: I32044e91b0c944c1b137efdceb3f01dfaa78119d
some of these failures are not fatal and even expected in some cases
so they should not emit a dump in the log in those cases.
Change-Id: Idcfa252e3bfa9d74e27fe4ad8f8623aa01aa9c5e
Bug #3081600
The OpenGL renderer in libhwui uses a single EGL context per process and
thus create it with an RGBA 8888 EGL configuration. To ensure that all
windows are compatible with this configuration, this change modifies
the window manager and SurfaceFlinger.
The window manager now checks the window's flags and if the window is
hardware accelerated, it forces the window's pixel format to be
translucent when creating the surface. The window itself is still
marked as opaque if we know that the window will be opaque on screen.
This keeps existing optimizations in place.
Similarly in SurfaceFlinger, a translucent Surface can now be created
with the Surface.OPAQUE flag, indicating SurfaceFlinger that the surface
does not require blending, despite its RGBA 8888 configuration.
Change-Id: Ic747b6b12564ba064412d842117880fcc199eb7c
the core screenshot function now can capture the screen at any lower resolution
performing bilinear filtering.
we also now have some client code to interface with the screenshot service.
it's now possible to request a screenshot at a lower resolution.
Change-Id: I33689bba98507ab928d0898b21596d0d2fe4b953
the core screenshot function now can capture the screen at any lower resolution
performing bilinear filtering.
we also now have some client code to interface with the screenshot service.
it's now possible to request a screenshot at a lower resolution.
Change-Id: I5a3b0e431421800e3aad601d9af8f94adffbc71f
The bug caused SurfaceFlinger to constantly trigger reallocation of buffers
that requested a fixed size.
Change-Id: Ic993a60e6474e36a344c8b48d541a0d08b8c4faf
Merge commit '468204124e95bbf74ae8cc000318ade29e311be6'
* commit '468204124e95bbf74ae8cc000318ade29e311be6':
don't try to lock a buffer that wasn't allocated with SW usage bits
Merge commit 'bc4389edfbb5777aec1a9af7863b2ca3ade2fa64'
* commit 'bc4389edfbb5777aec1a9af7863b2ca3ade2fa64':
fix [2931513] Add support for setting the orientation of an ANativeWindow
this situation happened when the last buffer needed to be resized
(or allocated, the first time). the assumption was that the buffer
was in use by SF itself as the current buffer (obviously, this
assumption made no sense when the buffer had never been allocated, btw).
the system would wait until some other buffer became the "front" buffer.
we fix this problem by entirely removing the requirement that the
buffer being resized cannot be the front buffer. instead, we just
allocate a new buffer and replace the front buffer by the new one.
the downside is that this uses more memory (an extra buffer) for a
brief amount of time while the old buffer is being reallocated and
before it has actually been replaced.
Change-Id: I022e4621209474ceb1c671b23deb4188eaaa7285
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Iee42b83dd2a94c3bf5107ab0895fe2dfcd5337a8
