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
this hack was used for gpus that don't support cached buffers
for s/w clients. currently we have no gpu with this issue.
this removes quite a bit of complexity.
Change-Id: I72564669f124f92805030e61983711f61c76b6d9
Merge commit '56aed6bde0c52658d2cb1207c0cfe8ba0a764c59' into kraken
* commit '56aed6bde0c52658d2cb1207c0cfe8ba0a764c59':
fix [2664345] Flash: Bad flicker at the end of a pinch zoom.
the window manger puts SurfaceViews up before they have been
rendered into, because of that surfaceflinger doesn't have
anything ready to draw for that surface when an udpate occurs
and responds by filling the surface with black.
With this fix, we only fill those areas of the framebuffer
that would otherwise be undefined (no content at all).
in the Flash case, the "flash" window is not drawn at all
until it has some content, instead the underlaying browser
window is shown.
Change-Id: Ifb610f7f8c27b88edf83e09adc4803fc295c15a1
get rid of the "fake rtti" code, and use polymorphism instead.
also simplify how we log SF's state (using polymorphism)
Change-Id: I2bae7c98de4dd207a3e2b00083fa3fde7c467922
Merge commit 'e7d5a2f9ae47d8ea8face3f1e451314ed36f4026' into kraken
* commit 'e7d5a2f9ae47d8ea8face3f1e451314ed36f4026':
fix [2594950] Flash: Zooming in on some content crashes the Nexus One and causes it to reboot (runtime restart)
We now limit the size of the surface to the maximum size supported by the GPU.
On Nexus One this will 2048 -- it could be different on other devices.
Surface creation fails if the limit is exceeded.
Change-Id: I9ecfc2e9c58c9e283782b61ebfc6b590f71df785
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.
