if a buffer couldn't be allocated because of an OOM, SF could, in some case dereference
a null pointer.
Change-Id: I5321248c38a21e56d5278b6aada2694e64451378
- 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.
This feature is currently controled by a system property.
"ro.sf.hwrotation" can be set to either 90 or 270. It'll cause
SF to rotate the screen by 90 and 270 degres respectively.
That is, if the driver reports 800x480 for instance, and
ro.sf.hwrotation is set to 90, applications will "see" a
480x800 display and will run in portrait.
This is implemented by introducing an extra "display"
transformation in the GraphicPlane.
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.
When a surface is removed from the screen while it holds a "freeze lock", the
release of that lock happens in the destructor as a "safety net". However, it
doesn't trigger an update at that point.
Make sure that "freeze locks" are released from the transaction at the point
a surface is removed from the screen (if it's not on screen, it shouldn't
prevent the screen to redraw, and therefore cannot hold a freeze lock).
The refresh corresponding to that transaction will pick it up as soon as possible.
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.
always rescale videos to their target size using copybit during yuv->rgb
conversion. this improves performance of the GPU pass and doesn't require
linear filtering to be enabled. Also always use 16-bits buffers.
the average processing time for 720p dropped from ~50ms to ~30ms
The image buffer used by glTexImage2d() would be uninitialized when no copybit engine
can be found.
We now always initialize images, since the abscence of copybit is not necessarily fatal.
There was bug in the logic that calculated the relative timeout, the start time was
reset each time an event was received, which caused the timeout to never occur if
an application was constantly redrawing.
Now we always check for a timeout when we come back from the waitEvent() and
process the "anti-freeze" if needed, regardless of whether an event was received.
since we're using the GPU for composition, don't use a texture for dimming,
instead simply use an alpha-blended quad.
also workaround what looks like a GL driver bug by calling glFinish() before
glReadPixels().
2206097: Broken suggestions while composing message
2166583: Color artifacts with MDP dithering
2261119: Passion transition animations are rough
2216759: Screen flicker when dropdown list in background window shows or hides
This is part of enabling GPU composition instead of using the MDP. This change
is dependent on another change in the vendor project.
Specifically this change disables the use of EGLImageKHR for s/w buffers
for cache coherency reasons. memcpy is used instead.
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.
we lost the concept of vertical stride when moving video playback to EGLImage.
Here we bring it back in a somewhat hacky-way that will work only for the
softgl/mdp backend.
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
Temporarily make a function public that doesn't need to be. When
host gcc-4.0.3 is gone from the build servers we can undo this.
(Cherry-picked from eclair-mr2.)
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
Instead of using glTex{Sub}Image2D() to refresh the textures, we're using an EGLImageKHR object
backed up by a gralloc buffer. The data is updated using memcpy(). This is faster than
glTex{Sub}Image2D() because the texture is not swizzled. It also uses less memory because
EGLImageKHW is not limited to power-of-two dimensions.
When switching rapidily orientation back and forth, surfaces end-up
acquiring the freeze-lock when the first orientation change happens,
but never release it because by the time the 2nd orientation change
comes in, the surface size is back to its original size and
doesn't appear to have resized.
we now always release the freeze-lock when we receive a buffer of the
expected size.
