To allow low-memory devices to reduce (or eliminate entirely)
the RAM used by the JIT, dalvikvm has a new command-line
option to set the max size of the JIT's translation cache.
In this CL, we pass that new option based on a system property.
Change-Id: I2a01da4d19c1922b6ed52791ee513efef9caf3d4
The eglGetSystemTimeNV extension can be used to enable profiling
in PerfHUD ES. When the delta of two calls to eglGetSystemTimeNV
equals 0, we now cancels display lists updates. This allows the
tool to redraw the same frame several times in a row to run its
analysis.
For better results profiling should only be attempted after
setting viewroot.profile_rendering to true using adb shell
setprop.
Change-Id: I02e3c237418004cff8d6cb0b9a37126efae44c90
Added support for teasing apart different parts of the dalvik heap.
Note this adds more public api and we should talk to hackbod before going into master with this.
(cherry picked from commit 73407daf3f6110e933d8614605b21586c4c5fde2)
Change-Id: If4431f50e67e18bcc42e00694c97805477bd6815
Breaking out oat footprint in meminfo.
(cherry picked from commit c92f177d96b5952e0bfde01597972fc607aed93a)
Change-Id: I7b0452045c265b7544c41d3a5953e10a081c5315
Although in practice an application or IME is unlikely to fill up
the input channel with finish events, it can happen when events are
being delivered very rapidly. Handle this situation by queuing
up the pending finish events until the socket becomes writable again.
Bug: 9034301
Change-Id: I938a62a75d12106a19cff2d016ba7af0db877ecf
SELinux get.. JNI need the 'security_context_t tmp' entries set
to NULL, otherwise on error freecon() tries to release uninitialised
memory causing apps to abort with invalid address.
Also fixed getPeerCon ALOGV call as this caused Zyote to abort when
verbose logging set.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
bug:8766924
Previously text bounds were calculated to be from 0 to totalAdvance in
the X, and from the font's top to bottom. These are incorrect,
especially in light of the font fallback mechanism.
Now, we calculate the bounds of the text as we layout each glyph.
Since these are much tighter bounds in the common case, this
significantly reduces the amount of clipping required (which in turn
enables more aggressive text merging).
Change-Id: I172e5466bf5975bf837af894a9964c41db538746
This preserves the existing behavior at the SDK level while skia
investigates a more comprehensive solution.
bug: 8986473
Change-Id: Ief82dcfd47f1ba08d28d43402b3c28694f94f2e4
This CL also updates the documenation to make it clear that the API
returns in local space, not clipped to the size of the bitmap/device.
bug: 8747526
Change-Id: I389844672ce955341863f9940c3b401ab00dc1dc
Adds an optimization for checking whether a looper is stuck,
with a new Looper method to see if its thread is currently
idle. This will allow us to put a large number of loopers
in the monitor efficiently, since we generally won't have to
do a context switch on each of them (since most looper threads
spend most of their time idle waiting for work).
Also change things so the system process's main thread
is actually running on the main thread. Because Jeff
asked for this, and who am I to argue? :)
Change-Id: I12999e6f9c4b056c22dd652cb78c2453c391061f
For fullwidth latin (or, more generally, a font considered as a complex
script, but not supported by the font specified), and for a font other
than a system default font, we were getting a mismatch in baseGlyphCount
between the shaping and painting fonts.
This patch preserves the original typeface in this case. In that sense,
it is a slightly more general fix for bug 8127795.
Change-Id: Ibdbfdb34eb7dc39cc8f0784a67c93c9af4ce6ab2
The counter can be enabled by setting the system property called
debug.hwui.overdraw to the string "count". If the string is set
to "show", overdraw will be highlighted on screen instead of
printing out a simple counter.
Change-Id: I9a9c970d54bffab43138bbb7682f6c04bc2c40bd
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
There were many places where the native object was being
accessed improperly. Also some places where CloseGuard might
not be acquired or released correctly or where the generation
count might not be updated.
Fixed them all.
That said, Surface isn't intended to be used concurrently
so please don't do it. This is only intended to make
hard to find crashes less likely.
Bug: 8328715
Change-Id: I981ef33425823e0fd7ad6b64443f2ec9b0c8335e
Add the ES-relevant constants from the EGL_KHR_create_context
extension. These allow apps to check which EGLConfigs (if any) support
ES3 contexts. Otherwise, the app has to create a context with an
EGLConfig and then check whether it is an ES2 or ES3 context.
Also move eglSetPresentationTimeANDROID from EGL14 to EGLExt, since it's an
extension function. It's new in API 18.
Bug: 8678160
Change-Id: I3cba6e59ebb0a3a4c4012aa54a36b940c288bcec
