Make sure to not use GL_TEXTURE_EXTERNAL when it's not supported
by the GL. The error was harmless, but annoying.
Change-Id: I571a9a9b05d35da51420950a6a6e95629067efd0
simplified things a lot, the biggest change is that the concept
of "ClientID" is now gone, instead we simply use references.
Change-Id: Icbc57f80865884aa5f35ad0d0a0db26f19f9f7ce
the new TextureMagager class now handle texture creation and upload
as well as EGL image creation and binding to GraphicBuffers. This is
used indirectly by Layer and directly by LayerBuffer
the new BufferManager class handles the set of buffers used for a
Layer (Surface), it abstracts how many buffer there is as well as
the use of EGLimage vs. regular texture ops (glTexImage2D).
Change-Id: I2da1ddcf27758e6731400f6cc4e20bef35c0a39a
get rid of the "fake rtti" code, and use polymorphism instead.
also simplify how we log SF's state (using polymorphism)
Change-Id: I2bae7c98de4dd207a3e2b00083fa3fde7c467922
- fix a bug when hacking video buffers into gralloc buffers
where the buffer size was incorrect this was causing the
"direct-form-texture" mode to fail
- also when the above fails, make sure to revert to the
"mdp copy mode" before going to "slow mode"
- finally disable completely the "direct-from-texture" mode
for now. It cannot work because the allocated buffers can't
respect the GPU constraints (alignment and such). We'll
have to find a solution for that.
We now always first try to use the EGLImageKHR directly before
making a copy with copybit. The copy may be needed when
EGLImage doesn't support the requested format, which is
currently the case with YUV.
make sure to fallback properly to software when copybit operation fails.
with this change, the preview image will at least be displayed in b&w
(since GL doesn't support the yuv format). This would also fix
2363506, but that one is now handled more cleanly.
this was introduced by a recent change. when we try to figure out the size of
the yuv->rgb temporary buffer, the output resolution has not been computed yet
and an invalid buffer size is used. most of the time the allocation fails
and the system reverts to "standard" GL will uses onle the Y plane.
the allocation of the temporary buffer is moved to onDraw(), the first
time it is called, by that time, the window is positioned properly.
This builds on the EGLImage solution. We simply use copybit to convert from the
YUV frame into an EGLImage created for that purpose and proceed with the
regular EGLImage code.
We need to do this because "regular" GL doesn't support YUV textures.
We could improve upon this by detecting exacly what the GL supports and bypass
this extra step if not required, but we'll do this later if needed.
add a way to convert a mapped "pushbuffer" buffer to a gralloc handle
which then can be safely used by surfaceflinger, without including
gralloc_priv.h
Use EGLImageKHR instead of copybit directly.
We now have the basis to use streaming YUV textures (well, in fact
we already are). When/if we use the GPU instead of the MDP we'll
need to make sure it supports the appropriate YUV format.
Also make sure we compile if EGL_ANDROID_image_native_buffer is not supported
When EGLImage extension is not available, SurfaceFlinger will fallback to using
glTexImage2D and glTexSubImage2D instead, which requires 50% more memory and an
extra copy. However this code path has never been exercised and had some bugs
which this patch fix.
Mainly the scale factor wasn't computed right when falling back on glDrawElements.
We also fallback to this mode of operation if a buffer doesn't have the adequate
usage bits for EGLImage usage.
This changes only code that is currently not executed. Some refactoring was needed to
keep the change clean. This doesn't change anything functionaly.
we ended-up locking a Mutex that had been destroyed.
This happened because we gave an sp<Source> to the outside world,
and were called after LayerBuffer had been destroyed.
Instead we now give a wp<LayerBuffer> to the outside and have it
do the destruction.
Rewrote SurfaceFlinger's buffer management from the ground-up.
The design now support an arbitrary number of buffers per surface, however the current implementation is limited to four. Currently only 2 buffers are used in practice.
The main new feature is to be able to dequeue all buffers at once (very important when there are only two).
A client can dequeue all buffers until there are none available, it can lock all buffers except the last one that is used for composition. The client will block then, until a new buffer is enqueued.
The current implementation requires that buffers are locked in the same order they are dequeued and enqueued in the same order they are locked. Only one buffer can be locked at a time.
eg. Allowed sequence: DQ, DQ, LOCK, Q, LOCK, Q
eg. Forbidden sequence: DQ, DQ, LOCK, LOCK, Q, Q
doesn't happen because the visibility never changes. With this change
the overlay parameter and position will be committed when either the visibility
of the window changes, or on the first call to visibility resolved, if it
hasn't already been done.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Surfaces are now destroyed once all references from the clients are gone, but they go through a partial destruction as soon as the window manager requests it.
This last part is still buggy. see comments in SurfaceFlinger::destroySurface()
