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
