A change in the VM triggers a native memory error more aggressively than before,
showing that there's a bug in the logic of recycling bitmaps. Since the pixel
memory is allocated on the Java heap, nulling out the reference to that memory
in the Java level Bitmap object can cause that memory to get collected at any time.
Meanwhile, we may have a reference to that memory at the native level for rendering
purposes, causing an error if/when we access that memory after it has been collected
by the VM.
The fix is to avoid setting the reference to the pixels to null unless we are
not referring to it in native code. This is determined at the time we call
recycle() - we return a boolean to indicate whether the native code is still
using the memory. if not, the Java code can null out the reference and allow the
VM to collect it. Otherwise, it will get collected later when the encompassing
Bitmap object is collected.
Issue #7339156 HTML5 tests crash the app (Vellamo)
Change-Id: I3a0d6b9a6c5dd3b86cc2b0ff7719007e774b5e3c
Bug #7353771
This API can be used when scaling large images down to a small size
to get nicer looking results.
Change-Id: If09087eed36077eee5355f6047a3ca67747d7d9e
The failures were caused by the implementation of doTextRunCursor
passing a too-small value for contextCount into the underlying
getTextRunAdvances call (it wasn't accounting for the start offset).
Thus, when getTextRunAdvances made a copy of the text for its cache key,
it was getting a partial copy.
This patch fixes the size so the cache key always has a full copy of the
text.
Change-Id: I57e3ac6de7aef0e1f1c7000dc3d653f9b0d623d2
This fixes bug 6948776
android.graphics.cts.PaintFlagsDrawFilterTest#testPaintFlagsDrawFilter
failures on JO
When we moved the drawing of text decorations (underline, strikethrough)
from Skia to our own drawing (so we could take into account the metrics
computed by TextLayoutEngine), we just used the raw flags from the
paint, which ignored the overrides that a DrawFilter can effect.
The patch simply checks for the existence of a DrawFilter in the canvas,
and applies it to a copy of the paint where present. This will be one
extra paint copy where the filter exists, but that's expected to be rare
(other than running this CTS test, of course).
Change-Id: I664c478b73a3a1cc43599ee11bbc02c69b7a96c2
This bug was triggered by user code concurrently mutating the character
array while calling into a drawText method in another thread. When the
value of the array changed, it caused inconsistent state, leading to
assert failures.
This is arguably bad behavior by the user code, but it shouldn't cause a
native crash. The fix is to do a defensive copy of the text into the
key, so the value is guaranteed to remain constant throughout the text
layout process. The change is mostly deletion of code, because there was
an optimization to try to avoid such a copy. That optimization was not
actually effective, however, because the indexOfKey() operation in the
KeyedVector underlying the TextLayoutCache did the copy anyway. Thus,
even though this change looks like it's introducing a copy where there
wasn't one before, the actual performance impact should be nil.
Note that the ability to handle a mutating argument is now part of the
contract for TextLayoutEngine::getValue(), and is now documented. That
contract may change, as the result of future optimization. Also, care
was taken to only use the value after the copy.
Other performance issues with TextLayoutCache are tracked in bug
7271109.
Change-Id: I9c90e8e4d501f3f37e2f22a7851f032808d46fbe
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
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
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
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
This change makes the SurfaceTexture JNI updateTexImage call the native
SurfaceTexture's doGLFenceWait method to perform the needed synchronization.
Change-Id: Ie70a1fe6b44d439d1ffe7b97689a421ff8c02fda
In some cases bitmap's pixels where freed during encoding, which
caused a null pointer dereference.
This fix makes sure that underlaying buffer is locked for the whole
process of compression.
Change-Id: I0ac56821f5d333072271dc2670fa30f1562adfa3
Cherry-pick Ib5dd86950156c5a438f25c289acb839206bb455a from master.
Data: label MTLmr3m with "ja" locale attribute, fallback_fonts-ja.xml removed,
as we only need a single fallback font file
Code: Add locale and variant to TextLayoutCache. Paint.java sets textLocale as
the language (for example, "ja") rather than the language/locale concatenated
(for example "ja_JP")
This checkin, along with Change-Id: Id8c91ae0be6cad8a7ef77a0cd5803676290986c1,
allows text view objects to set their locale dynamically and skia will use the
correct font for the locale.
Change-Id: Ieb60b0d7a39fcfef4f8ce90cd4f6065d33673710
Corrected a small typo where Java InputStream methods are
incorrectly checked when creating a JNI InputStream adaptor.
Change-Id: I5f14897e0d5ddceb4b2af6be46769713f0487624
The mark positioning changes increase the number of bytes needed per
glyph from 6 to 14. This patch compensates by allocating more total
memory for the text layout cache.
Change-Id: I3cf59547394a41779cf6e92e67688b0fdc85f1a3
I meant to log certain debug values only when DEBUG_GLYPHS was set, but
I used #ifdef instead of #if (when it's not set, it's 0, rather than
undefined).
Change-Id: Ic27fee7dd355009c1873f0a2e12614849bbceebd
This patch implements glyph positioning in the Skia-based renderer. Note
that it depends on a fix for bug 6833339 being in place (correct
calculation of advance widths under skew and scale transforms),
otherwise there will be regressions.
Careful attention was paid to correct results in a wide variety of
conditions: alignments, text decorations, scale, skew, etc. Many of
these are exercised in the test app attached to bug 6833339.
Note that this patch also changes slightly the way that the total
advance is calculated - the running is accumulated and passed through to
computeRunValues(), so that the x positions of each glyph can be set
according to the total advance of all glyphs (in all runs) appearing
before (plus, of course, the offset for mark positioning).
After committing this patch, text rendering will no longer match between
the software and hardware rendering cases. Implementing positioning in
the hardware renderer will resolve that, and fully implement bug 5443796.
Change-Id: Ie0f7835d48bc120475a19afbfe159aa5304fcaa8
There were a number of extraneous typeface pointers, one per
language, in TextLayoutCache. Removing these makes adding additional
supported fonts easier. This checkin now properly
unrefs typefaces returned by SkCreateTypefaceForScript. Additionally,
all harfbuzz shaped fonts (with exceptions Greek, Cyrillic, Hangul)
should call SkCreateTypefaceForScript.
Change-Id: I7dcf603a89e5ff52c6dab8fb87ae1807a79c351c
If an app used a GIF file in the wrong density bucket, the auto-scaling
code would not properly resize the bitmap.
This issue affects third party applications, here is the external bug
report:
http://code.google.com/p/android/issues/detail?id=34619
DO NOT MERGE
Change-Id: I7f99b28ad6e6c28bdbcb29bbbadcb215268ff710
If an app used a GIF file in the wrong density bucket, the auto-scaling
code would not properly resize the bitmap.
Change-Id: I28f6506a94b20d11b3ba53ac442abec2b92e093e
Harfbuzz apparently requires the offset array to be initialized to zero,
otherwise it can report corrupt glyph positions. This change also
contains a small amount of refactoring to avoid code duplication.
Change-Id: I2553974f40bc8e0549876c7d31243960ca92a8a2
Some of the logging lines referred to the "path" variable which no
longer exists. We log the Harfbuzz script instead, which hopefully
provides enough context.
This change only affects debug builds, but we will want to be working
intensively in this space.
Change-Id: I86c3b58c9fa2a8c47812ef5f0b5ce64fd8dcdc20
Fonts can be marked with elegant or compact in fallback_fonts.xml.
Webkit uses elegant fonts, Textview uses compact fonts (the default),
unmarked fonts are used by both.
Bug: 6649136
Change-Id: Ie0debcddc13350bf60fe3139cd7ae533e466f02b
TextLayoutCache was leaking HB_Face objects, not freeing them when
purging the mCachedHBFaces cache. More full analysis is in the bug.
Change-Id: Ie5cd8b00c36b9d31963183c601cde49cbb73fafb
- add missing cached data clearing. The Shaper was caching the HB_Face so
clear them too
- do minor code refactoring
Change-Id: Ifa86cc63815bdb4b51ce688cf16e986415b1e8c1
In one particular error case, we might exit the function without
destroying the bitmap.
Bug: 6467873 (tangentially related)
Change-Id: I3a213cc0a53023d9d0d2a080aed15774f4c4c10c
