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
This is the real fix to issue 6158892. We currently delete
transform/camera structures at DisplayList destructor time, if these
structures are not NULL. We set the fields to NULL in an init() method
called (eventually) by the constructor. But it is possible for the object
to be destroyed before that init code is called, resulting in the deref
bug reported. The fi is to set these structures to NULL directly in the
constructor.
Issue 6158892i: Device runtime restarts frequently
Change-Id: Ibfa0f9314767eed6fd51f4ec7edc0d0edd5fdd0f
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
glGetError() was invoked every time a display list was updated. This
was unnecessary since display list updates do not execute OpenGL code.
Change-Id: Ia0a75a65ccf2a4701fb3a828848cd0c42f256c6c
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
This adds basic support for clip regions. It is currently disabled at compile
time. Enabling clip regions will require setting up a stencil buffer.
Change-Id: I638616a972276e38737f8ac0633692c3845eaa74
The Snapshot class is getting complicated enough that its implementation
should now live in a separate .cpp file. This will become particularly
useful when support for clip regions and paths will be added later on.
Change-Id: I050fac5683a9f7a0ff2f7a6beec3dd28aa5eb0d8
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
- it was a regression introduced into this CL: https://android-git.corp.google.com/g/#/c/154240/5
- basically needed to set the GlyphID encoding to the Skia Paint as we are now using glyphID resulting
from the Harfbuzz shaping
- also define GlyphID encoding as the default on the Paint class
Change-Id: Idb7c2c57ac67595425ce3be9421258962690fcdd
Currently, font renderers eliminate some texture caches when
memory is trimmed. This change makes it go further by eliminating the
large-glyph caches for all font renderers. These caches are
only allocated as needed, but continue to consume large amounts of
memory (CPU and GPU) after that allocation. De-allocating this memory
on a trim operation should prevent background apps from holding onto
this memory in the possible case that they have allocated it by drawing
large glyphs.
Change-Id: Id7a3ab49b244e036b442d87252fb40aeca8fdb26
There were 2 issues remaining after a recent change to support
glyph caching from multiple textures:
- memory in the GPU for all textures was being allocated automatically.
This is now lazy, being allocated only when those textures are first
needed.
- filtering (applied when a rendered object is transformed) was ignoring
the new multiple-texture structure. Filtering should be applied correctly
whenever we change textures.
Change-Id: I5c8eb8d46c73cd01782a353fc79b11cacc2146ab
Some GPU architectures could not handle the previous implementation
of our glyph cache. Frequent uploads would cause memory problems in the GPU
and eventually a crash due to these memory issues. The solution is to move to
a system of several, smaller caches instead of one monolythic cache for all
glyphs.
Change-Id: I0fc7a323360940d16d5a33eeb33abfab194c5920
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
