bug:8037003
The reordering enables similar operations to draw together, minimizing the
OpenGL state change operations that go inbetween draws. Eventually, multiple
complete canvas draw operations will be merged (into a single glDrawArrays call,
for example)
Reorders DisplayList draw operations when:
-They can move backwards in the command stream to be after similar
operations without violating draw ordering
-The OpenGLRenderer is in a simple, replayable state (no complex clip,
or filter/shadow etc)
Also adds two system properties to control the deferral/reordering:
"debug.hwui.disable_draw_defer"
"debug.hwui.disable_draw_reorder"
which can be set to "true" to control the display list manipulation
Change-Id: I5e89f3cb0ea2d2afd3e15c64d7f32b8406777a32
This reverts commit 6c0307dd0aefe9a08794b155fc03ee60ebd14f25, reversing
changes made to a2cd828b749c444d55c2c41c7dbb85088ff94b9f.
Conflicts:
packages/SystemUI/res/values-sv/strings.xml
Change-Id: Ia178efe8b14751583d47b2826bfe3d3d5463dd2e
bug:8037003
Changes the DisplayList from using stream read/write commands to use an array of
objects manually allocated on a linear buffer.
Depends on frameworks/native change https://googleplex-android-review.googlesource.com/#/c/257695/ which adds LinearAllocator
Also changes drawRects to use float count instead of rect count, to be more like drawLines/drawPoints
Change-Id: Ia2e4a11acd8f0a757042a05cbc9e7563cb73ee47
Region clipping, using Canvas.clipPath or Canvas.clipRegion, requires
a stencil buffer to be always present. In addition, extra wiring is
required in JNI and display lists.
This change only adds the necessary JNI/C++ APIs and some extra
plumbing to start the real work on properly supporting region
clipping.
A new debug define called DEBUG_CLIP_REGIONS can be used to draw
the current clip region. It is off by default, as is region
clipping.
The default implementation of clipPath() and clipRegion(), now
in native, mimics the previous Dalvik implementation to prevent
regressions.
Change-Id: I7903e7cfd7412b9b9b622566d4dbfce7bdcec00c
When profiling is enabled with debug.hwui.profile set to true,
setting debug.hwui.profile_visualizer to true will display the
profiling data directly on screen.
Change-Id: I3d5fe3f0347090815087b1cbfce66b8e76d9347b
Bug #7326824
When a layer is taken out of the cache and initialized it gets cleared
to prepare it for future rendering. This triggers the following sequence
of operations:
glBindFramebuffer(layer.fbo)
attach texture storage to FBO
glClear()
glBindFramebuffer(defaultFbo)
The clear forces a resolve on tilers which stalls the CPU for a little
while, thus producing jank during animations. This change moves the
clear to the next frame when we know we will have to execute a resolve
anyway.
Change-Id: Ic1939c25df20ed65a4c48dc81ee549b2cd8b6ec3
When memory gets low on a device, activities flush everything they can.
Hardware-accelerated activites, such as Launcher, flush GL resources and destroy
the GL context. However, some resources were still hanging around, due to deferred
destruction policies (we don't delete layers until the DisplayLists they are in
are finalized, to ensure we don't deref deleted objects). This meant that we were
referring to obsolete GL data in these objects. in particular, it meant that we might
come around later, after a new GL context was created, and delete a texture object
that was incorrect. We use the layer's "texture id" to refer to the texture underlying the
layer. But if there's a new GL context, then this texture ID is no longer valid, and
we may be deleting the texture that a different object (layer, icon, whatever) is referring
to, because the driver may return that same ID under the new GL context.
The fix is to more aggressively delete things that we know will not be used again
when the GL context is destroyed. In particular, we delete all resources being used
by all DisplayLists at GL context destruction time.
Issue #7195815 Textures corruption on all devices, in many apps
Change-Id: I52d2d208173690dbb794a83402d38f14ea4c6c22
Launcher occasionally crashes with a stack trace indicating that the memory
of a Layer object is corrupt. It is possible for us to delete a Layer
structure and then, briefly, use it to draw a DisplayList again before
that DisplayList gets recreated (without the layer that got deleted).
When this happens, if the memory got corrupted, it's possible to crash.
The fix is to add Layer to the other objects which we currently refcount
(bitmaps, shaders, etc.). Then instead of deleting a Layer, we decrement the
refcount. We increment when creating it, then increment it again when it's
referenced from a DisplayList. Then we decrement the refcount instead of
deleting it, and decrement when we clear a DisplayList that refers to it.
Then when the refcount reaches 0, we delete it.
Issue #6994632 Native crash in launcher when trying to launch all apps screen
Change-Id: I0627be8d49bb2f9ba8d158a84b764bb4e7df934c
There are two fixes here:
- precaching: instead of caching-then-drawing whenever there is a new
glyph, we cache at DisplayList record time. Then when we finally draw that
DisplayList, we just upload the affected texture(s) once, instead of once
per change. This is a huge savings in upload time, especially when there are
larger glyphs being used by the app.
- packing: Previously, glyphs would line up horizontally on each cache line, leaving
potentially tons of space vertically, especially when smaller glyphs got put into cache
lines intended for large glyphs (which can happen when an app uses lots of unique
glyphs, a common case with, for example, chinese/japanese/korean languages). The new
approach packs glyphs vertically as well as horizontally to use the space more efficiently
and provide space for more glyphs in these situations.
Change-Id: I84338aa25db208c7bf13f3f92b4d05ed40c33527
This implementation adds a drawGeneralText() method to the OpenGL
Renderer, which supports both a global x, y position, an array of
individual glyph positions, and also a length parameter (which enables
drawing of underline and strikethrough. It also adds the method to the
display list (with marshalling and unmarshalling).
With this change, the existing drawText() method is removed entirely, as
it's subsumed by the new method. It's easy enough to revert to the old
functionality if needed by passing in a NULL positions array.
Change-Id: I8c9e6ce4309fd51cc5511db85df99f6de8f4f6f5
A previous fix made it necessary for a frame to render something to GL
in order to cause a call to eglSwapBuffers(). Besides the calls being
tracked as part of issuing a DisplayList, there is also a potential call
to clear the canvas (via glClear()) on non-opaque surfaces. This call is also
good to track, since a surface that gets cleared without any other drawing operations
is worth flipping to the screen (to erase old contents on that surface).
This fix tracks the status of the pre-draw operations to find out whether
glClear() was called and then sets the drawing status appropriately.
Issue #6606422 QuickContact dismissal is janky again (Tracking)
Change-Id: I5fcaccfdc9293dd46b83f2fc279730a5d2740ebf
The fix is to track when we issue GL drawing commands, and to skip the
call to eglSwapBuffers() when a DisplayList does not result in
any actual rendering calls to GL.
Issue #6364143 QuickMuni list items and buttons flicker instead of fade
Change-Id: I60a02c61a58c32d92481a1e814b4c8a49c6a37a3
The comparisons used in the various properties setters could fail badly
in some specific conditions. The scale properties in particular did not
use the same comparisons.
This change also clamps alpha to the 0..1 range which avoids overflow
issues with lowp registers in GLSL computations.
Change-Id: I3e73b584e907a14e2c33d0865ca0d2d4d5bff31d
Some logic in the native matrix code would determine that a matrix was
'pureTranslate' based on the scale values of a matrix being close-enough to 1,
which was within a very small epsilon. This works in general, because screen space
coordinates make that epsilon value irrelevant, so close-enough really is close-enough.
However, TextView, when centering text, works in a coordinate system that is quite
huge, with left/right values about 500,000. These numbers multiplied times that small
epsilon value would give a result that was significant, and would cause a miscalculation
of up to 4-5 pixels, causing the snap that we'd see for a couple of frames as the
scale got "close enough" to 1.
The fix is to remove the optimization of "close enough". What we really need the matrix to
do is to identify itself as being translate-only when no scale as been set (which is the
default). For the purposes of that check, it is good enough to simply check the values against
1 directly. Similarly, the bounds-check logic needs to check against 0 and 1 directly.
Issue #6452687: Glitch when changing scale of a view containing text
Change-Id: I167fb45d02201fb879deea0e5a7ca95e38128e17
An optimization for paths is to only create a texture for the original native
Path object, and have all copies of that object use that texture. This works in
most cases, but sometimes that original path object may get destroyed (when the
SDK path object is finalized) while we are still referencing and using that object
in the DisplayList code. This causes undefined errors such as crashes and hanging
as we iterate through the operations of a destroyed (and garbage-filled) path object.
The fix is to use the existing ResourceCache to refcount the original path until
we are done with it.
Issue #6414050 Analytics Dogfood App crashes reliably on Jellybean
Change-Id: I5dbec5c069f7d6a1e68c13424f454976a7d188e9
This flag was still hanging around pending any need to disable
DisplayList properties. But things seem stable, so it's time to clean up
and simplify the code.
At the same time, I reduced redundance in DisplayList dimensions. We
used to call drawDisplayList() with width/height parameters that were
used to do a clip reject. This is redundant with the DisplayList properties
that set the bounds of the DisplayList; the left/right and top/bottom properties
represent the same width/height properties formerly used in drawDisplayList().
The new approach is to not pass dimensions to drawDisplayList(), but to
instead pull those dimensions directly from the DisplayList when needed.
Change-Id: I8871beff03b1d4be95f7c6e079c31a71d31e0c56
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
An earlier commit fixed problems with enabling DisplayList properties.
This CL actually enables the properties.
Change-Id: I5c41d0c64e9241822af53eb367de0fed7d9608e0
Re-enabling DisplayList properties last week caused some app
errors due to the way that some transforms were being handled (specifically,
those coming from the old Animations and ViewGroup's childStaticTransformation
field). This change pushes *all* transform/alpha data from View.draw() into
the view's DisplayList, making DisplayLists more encapsulated (and correct).
Change-Id: Ia702c6aae050784bb3ed505aa87553113f8a1938
The new DisplayList properties design has ordering conflicts with the
way that alpha works with old animations (AlphaAnimation). This CL
disables DiksplayList properties while I'm working on a fix and some
more thorough tests for old animations-vs-DL properties in general.
Change-Id: I8f6893138f939171491c2ec3c889214ee55d17b7
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
DisplayList properties are (again) disabled by default, via flags in
View.java and DisplayListRenderer.h. There are various artifacts to
chase down before enabling by default.
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.
Change-Id: I045dc82ce1d85fedbae3bb88eb2a2dfb6891d41f
This CL simply enables DisplayList property functionality. The code for
this feature is already there, but it's been disabled by default pending further
testing and analysis. This change sets these build-type flags to true
so that all hw-accelerated apps will now use DisplayList properties by default.
In particular, this feature enables a fast-path for changes that affect the
handful of View properties involved in animations (alpha, translationX, etc.).
Setting these properties now gets propagated to the native DisplayList associated
with the View, avoiding costly recreation of the SDK-level DisplayList and
also enabling faster invalidation of the view hierarchy.
Change-Id: Ic99c8f28fa9183f2e54e9e4860b333eb9c540f7c
Bug #6157792
Previously, DisplayListRenderer would compute the number of bytes
written after a drawing op by looking at the difference between
the start pointer of the command stream and the end pointer of
the command stream. The SkWriter class used to record the commands
stream allocates blocks of storage which would cause a crash when
a command spanned two blocks.
Change-Id: I4d79d3feeb6d72d9d4e6ab05ecebd72d004be56c
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
Bug #6073717
Bug #6065504
Bug #6026515
Bug #5971725
Prior to this patch, the destructor of DisplayList would always run
on the finalizer thread. This could cause a race condition if the UI
thread was busy rendering display lists at the same time leading to
various random native crashes.
Change-Id: Ie11108e3b1538d4b358a1a8b4cce1b2d33152d0c
When a drawPath command is recorded in a display list, a copy of the
source path is made to preserve against possible modifications of the
said source path. Copies are discarded when a display list is cleared,
which usually happens on invalidate(). This means that even if a path
is never modified, the texture generated to draw it on screen is
destroyed every time an invalidate() is issued. This change fixes this
problem by introducing a reference to the source path in the copy.
If both the copy and the source path have the same genID, they are
the same path and can share the same texture.
Change-Id: I34849311c183e06336a1391d2d1568a087f973f6
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
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
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
