Bug #3515248
The problem is caused by the fast path when compositing layers on screen.
The fast path draws a single quad using glDrawArrays() whereas the general
path draws an arbitrary mesh using glDrawElements(). It looks like there's
an issue in the driver since glDrawArrays() is significantly slower than
glDrawElements() for a quad (6 vertices!)
This change just gets rid of the fast path.
Change-Id: Ib2361253ec67f44a988270f76c183422f12ce537
Bug #4093871
This bug was introduced by a change that modified the way fade areas
are cleared. The previous change relied on Rect::intersect() to empty
the intersected rect when the two rects don't intersect. Unfortunately
this is not what intersect() does. The fix is rather simple and
sets the layer's bounds to empty when they don't intersect with the
clip or the viewport. This has the side effect of ignoring the layer
which is the expected result.
Change-Id: Icf0038b9a476c53f8eff7084136aba3033d093e6
Bug #4092053
The problem always existed but was made visible by partial invalidation.
When saving a layer, the renderer would try to postpone glClear()
operations until the next drawing command. This however does not work
since the clip might have changed. The fix is rather simple and
simply gets rid of this "optimization" (that turned out to be
usless anyway given how View issues saveLayer() calls.)
This change also fixes an issue with gradients (color stops where
not properly computed when using a null stops array) and optimizes
display lists rendering (quickly rejects larger portions of the
tree to avoid executing unnecessary code.)
Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
Bug #3461349
This change also fixes two bugs that prevented partial invalidates
from working with other views. Both bugs were in our EGL implementation:
they were preventing the caller from comparing the current context/surface
with another context/surface. This was causing HardwareRenderer to always
redraw the entire screen.
Change-Id: I33e096b304d4a0b7e6c8f92930f71d2ece9bebf5
Bug #3431907
When drawing layers inside a layer, the wrong target FBO would be used.
This would happen for instance with app widgets using a ViewFlipper
in Launcher. The ViewFlipper uses a fade animation that triggers a
call to saveLayerAlpha(), which in turns creates an FBO. If this happened
during a scroll, the ViewFlipper's FBO would be composited back directly
inside FBO 0, i.e. the screen. This properly initializes the snapshots
of hardware layers to use the layer's FBO as the default compositing
target instead of using 0.
This problem did not happen when drawing hardware layers inside
hardware layers because LayerRenderer already takes care of figuring
out the FBO it needs to composite into. The bug would occur only
with layers generated with saveLayer() and its saveLayerAlpha()
variation.
Layers inside hardware layers insider layers inside hardware layers
now work properly.
Change-Id: Ibe852301087f3d414ad8a18436eebc81f8ac66f5
Bug #3409580
This bug affects anything that draws a 9patch inside a layer, this includes
launcher's workspace, all of the fade animations, etc.
Change-Id: Icbe8ecd158e3d5f44d07516462de68c5d1fb0a8f
Bug #3413433
This helps Launcher when a widget updates during a scroll, or when interacting
with widgets on the workspace if layers are still turned on.
Change-Id: Ic7a42eb34f74f4ae988039754f815e2efd1d1e4f
Bug #3385247
- The layer's alpha was interpreted in the wrong range 0..255 instead of 0..1
- 9-patches would not correctly dirty the layer region, the generated mesh
was incorrect
Change-Id: I4916249bedcdb0794929f3796bd17854971efc88
Previously, display lists were used only if hardware acceleration
was enabled for an application (hardwareAccelerated=true) *and* if
setDrawingCacheEnabled(true) was called. This change makes the framework
use display lists for all views in an application if hardware acceleration
is enabled.
In addition, display list renderering has been optimized so that
any view's recreation of its own display list (which is necessary whenever
the visuals of that view change) will not cause any other display list
in its parent hierarchy to change. Instead, when there are any visual
changes in the hierarchy, only those views which need to have new
display list content will recreate their display lists.
This optimization works by caching display list references in each
parent display list (so the container of some child will refer to its
child's display list by a reference to the child's display list). Then when
a view needs to recreate its display list, it will do so inside the same
display list object. This will cause the content to get refreshed, but not
the reference to that content. Then when the view hierarchy is redrawn,
it will automatically pick up the new content from the old reference.
This optimization will not necessarily improve performance when applications
need to update the entire view hierarchy or redraw the entire screen, but it does
show significant improvements when redrawing only a portion of the screen,
especially when the regions that are not refreshed are complex and time-
consuming to redraw.
Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
The renderer was checking whether the layer's region is a rect to
draw it with a simple quad. This test was done against the layer's
region structure, which was cleared after generating the mesh.
Unfortunately Region::isRect() returns true when the region is
empty, which was causing the renderer to always use a quad to
draw a mesh on screen.
Change-Id: If4b874579ee0cedcb67367c9efa5c0c98ca55231
With this change, the rendere keeps track of what regions are rendered into
and generates a mesh that matches these regions exactly. The mesh is used
to composite the layer on screen.
Change-Id: I1f342576b9134fb29caff7fb8f4c1da179fe956d
The new implementation relies on OpenGLRenderer's existing layer
code instead of duplicating it. The new code is much cleaner, with
simpler and better APIs and allows tracking of drawn regions inside
layers. Region tracking is not yet enabled but this will be done
in a future CL.
Change-Id: Ie826121a2227de8252c77b992a61218defea5143
With this new backend, a hardware layer is only recreated when
its associated view is udpated. This offers fast composition
in GL and fast update of the layer in GL as well.
Change-Id: I97c43a612f5955c6bf1c192c8ca4af10fdf1d076
This change detects what area of a layer was drawn into and generates a mesh
to match this area exactly. This can be used to avoid blending empty pixels
when the layer is composited.
This change also adds proper layers support to lines rendering and implements
layers composition in a more readable way.
Change-Id: I4a5588b98b19bd66891ebdc39631b193c5e31999
This API can be used to back a view and its children with either a
software layer (bitmap) or hardware layer (FBO). Layers have
various usages, including color filtering and performance
improvements during animations.
Change-Id: Ifc3bea847918042730fc5a8c2d4206dd6c9420a3
Bug #3282805
This bug was introduced with a previous refactoring. This also fixes
issues with setting the alpha when drawing bitmaps.
Change-Id: Id47641d26a4536c7e540041f92243bf6db9fc96d
This is the first step of the refactoring:
- drawColorRect
- drawTextureMesh
Remaining methods to refactor:
- setupTextureAlpha8
- drawPath
- setupShadow
- drawText
- drawLines
- composeLayerRegion
Change-Id: I0fced6a05b6b6eee10ee7cef0c3fbdaa6cefab20
