Some views (such as ImageView and TextView) handle non-opaque alpha
values directly. This was originally an optimization, but we can handle it faster
in many cases without this optimization when DisplayList properties are enabled.
Basically, if a view has non-overlapping rendering, we set the alpha value directly
on the renderer (the equivalent of setting it on the Paint object) and draw each
primitive with that alpha value. Doing it this way avoids re-creating DisplayLists
while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties.
Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
Bug #6258973
When flushing the layer caches we would attempt to delete the FBOs
associate with layers in the cache. The FBO property was however not
always properly cleared when recycling layers.
Change-Id: I7dedfe391d659a0849f1e1d84df17313b2c6e2b2
Several issues came up after DisplayList properties were enabled,
so they were disabled pending fixes. Those issues have been fixed, so
DisplayList properties are once again being enabled by default. This
CL both re-enables these properties (in View.java and DisplayListRenderer.h)
and fixes the various issues that enabling them caused the first time around.
Related issues (all currently marked as Fixed, though that was simply because
DL properties were disabled - this CL provides the real fixes now that
DL properties are enabled by default):
Issue #6198276 Text input broken
Issue #6198472 Native crash at pc 00076428 in many different apps in JRM80
Issue #6204173 Date/time picker isn't rendering all parts of UI
Issue #6203941 All Apps overscroll effect is rendered weirdly/has flickering
Issue #6200058 CAB rendering issue - not drawing items?
Issue #6198578 Front camera shows black screen after taking picture.
Issue #6232010 Layers not recreated when children change (DisplayList properties)
Change-Id: I8b5f9ec342208ecb20d3e6a60d26cf7c6112ec8b
WebView needs more fine-grained control over the behavior of the
framework upon execution of the display lists. The new status_t
allows WebView to requests its functor to be re-executed directly
without causing a redraw of the entire hierarchy.
Change-Id: I97a8141dc5c6eeb6805b6024cc1e76fce07d24cc
Basic functionality of handling View properties (transforms,
left/right/top/bottom, and alpha) at the native DisplayList level.
This logic is disabled for now (via compile-time flags in View.java and
DisplayListRenderer.h) as we continue work on it (there is no advantage
to the new approach until we optimize invalidation and rendering paths
to use the new code path).
Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
This optimization allows us to quickly skip operations that lie
entirely outside of the known bounds of a display list. Because
of ViewGroup.setClipChildren, we must keep the operations recorded
in the display list. setClipChildren(false) is however a very
uncommon operation and we will therefore often benefit from this
new optimization.
Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
The render threat is likely to break your application if you initiate it.
As such it must be explicitely requested using the following meta-data
tag in your manifest's application tag:
<meta-data android:name="android.graphics.renderThread" android:value="true" />
Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
These markers will be used to group the GL commands by View in the
OpenGL ES debugging tool. This will help correlate individual GL
calls to higher level components like Views.
Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
This optimization along with the previous one lets us render an
application like Gmail using only 30% of the number of GL commands
previously required
Change-Id: Ifee63edaf495e04490b5abd5433bb9a07bc327a8
I don't know who's to blame, SGX or Tegra2 but one of those two GPUs is not
following the OpenGL ES 2.0 spec.
Change-Id: I2624e0efbc9c57d571c55c8b440a5e43f08a54f2
Bug #5706056
A newly introduced optimization relied on the display list renderer
to properly measure text to perform fast clipping. The paint used
to measure text needs to have AA and glyph id encoding set to return
the correct results. Unfortunately these properties were set by
the GL renderer and not by the display list renderer. This change
simply sets the properties in the display list renderer instead.
This change also improves the error message printed out when the
application attempts to use a bitmap larger than the max texture
size.
Change-Id: I4d84e1c7d194aed9ad476f69434eaa2c8f3836a8
There was an error in some of the OpenGL layer logic such that we would
occasionally set up a layer for rendering and then not clean up when it was
done. This caused future OpenGL rendering to go into that layer instead of
to the buffers being displayed on the screen, resulting in artifacts including
flashes and displaying of stale content. This happened specifically when
using the wifi settings dialog with the InputMethod keyboard displayed,
but it was probably visible in other situations as well.
Issue #5628248: Flickering/flashing after entering password for WiFi
Change-Id: I38139f620b310f4309570fa7224552d2ee633999
Bug #5650514
After invoking a GL functor, libhwui restores a few OpenGL states
including the current FBO. The renderer was however making the
wrong assumption that the FBO to restore to was the base layer
instead of the FBO associated with the current canvas state.
Change-Id: Ie565500832ebffd673f6a43b83422d6cc05470a0
IMPORTANT: this change needs two patches for Harfbuzz:
- one concerning hb_utf16_script_run_prev() which was not returning the correct "previous" script
- one for the "script_properties" table that was missing Arabic code point ranges and declaring
HB_Script_Inherited instead of HB_Script_Arabic
The current change is doing the following:
- pass the correct typeface for Harbuzz shaping (depending on the script of the run)
- offset correctly the glyphIDs returned by Harfbuzz
We need to offset the glyphsID as Harfbuzz will return local glyphIDs (meaning in the
local range of the font used for shapping).
We then cannot use those glyphIDs when we are using a fallback Font (Arabic, Hebrews...)
because the FontRenderer needs glyphIDs in the range of all the Fonts (including the fallbacks)
Change-Id: I494897435bbc59293b02392ee2059cebcdf0e571
