Copy and paste error where wrong compare meant the code thought a target
utilization option was specified even if there wasn't one.
b/7062303
Change-Id: Ibf1c6cf72743c5fbec7618a719d12d0373184754
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
Bug #7221449
SurfaceTexture already deletes the GL texture when detachFromContext
is invoked. The newly introduced refcount would casue the Layer
object to be destroyed later and attempt to delete the GL texture
again. By the time the second cleanup occurs, the texture name
might have been reused by somebody else, resulting in erroneous
behaviors.
Change-Id: I257c589fea64b34c00f46fbfaa7732e6854a5e41
The getTextRunAdvances() method wasn't accounting for the true width of
the text. On closer examination, in Tamil the clusters consist of a
number of glyphs each of which has a nonzero advance (in some other
scripts, the first glyph in the cluster has an advance, and others are
effectively zero). Previously, we were just using the advance of the
first glyph in the cluster. This patch changes the behavior to sum the
advances of all the glyphs within the cluster.
Change-Id: I77a51235f4bb0dfaa72cbb920a8c3b217ad25404
Bug #7158326
When scissor optimization is enabled, OpenGLRenderer will attempt to
minimize the use of scissor by selectively enabling and disabling the
GL scissor test.
When the optimization is disabled, OpenGLRenderer will keep the GL
scissor test enabled and change the scissor rect as needed.
Some GPUs (for instance the SGX 540) perform better when changing
the scissor rect often than when enabling/disabling the scissor test
often.
Change-Id: Idb68862e287a23358f9188d577ae0f86161902fd
When decoding an image with scaling, if the allocation of the bitmap
data for the scaled bitmap failed, we were just ignoring it and going
on. This was yielding strange native crashes (bug 7196860 and bug
7175536). This patch checks whether the allocation succeeds, and returns
a null bitmap if not.
Of course, if the app really is OOM because it's allocated too many
bitmaps, it'll still get the OOME, but that's a lot nicer than a native
crash or memory corruption.
Change-Id: I8384059ab11c2ab9e93e283b9438d79e6709b7b1
This call is no longer needed as the default behavior of the native
SurfaceTexture class is to do the wait whenever updateTexImage is called.
Change-Id: I995686a5989409e21b00fac913bd33c11f806998
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 was the possibility for a race between clearing the caches and
using fonts. This patch simply protects both under the same mLock held
by the TextLayoutCache object.
Change-Id: Ib366e16a9a9ba702a46bc078d1bc0602713991e5
