bug:8875715
Additionally moves op logging before the op is executed, to print
correctly, in pre-order traversal
Change-Id: I4e9566261f8363c73739d183e6d82b854f72ffad
Bug #8833153
If Atlas::terminate() is called twice without an init() in between
libhwui would double-free Atlas::mImage. This lead to a lot of crashes
with the monkeys as they can easily trigger memory trims.
Change-Id: I96798414e5e71cd498aaca85a790661ebccdaa91
Bug #8808886
Without this conversion, alpha was always set to 0 or 1 which causes
things to disappear mysteriously. Mysteries are meant to be solved
and I solved them all in 6 characters.
Change-Id: I2078420fbe968c046e999b0eabb24403e71108fd
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
Sometimes views that are scaled leave behind rows/columns on the
screen as they move/scale around.
The problem was that the pivot point around which the scale takes place
(in the default case of scaling around the center of the view)
was getting truncated to integer coordinates in the display list.
Meanwhile, the pivot point at the Java level was using the true float
values, resulting in a mis-match between the invalidation rectangle
(computed at the Java level) and the drawing-operation rectangle (computed
at the native level).
This only occurred when views had odd bounds (thus the integer representation
of the center differed from the float representation of the center), and only
when some other drawing operation would expand the clip rect to allow the
incorrect drawing operation (using the wrong pivot point) to draw outside of
its clip boundaries.
Issue #8617023 7x7 screen not updated correctly
Change-Id: If88889b9450d34535df732b78077a29b1f24802d
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
Changes:
- The static device version of libandroidfw now includes
the extra functions needed by aapt. I could only find
a few host tools that use the static library, so this is
hopefully not a problem.
- The pseudolocalization code is moved into aapt.
It was previously in libhost, but only used by aapt.
Change-Id: Ib393ebb7dcebee8abbb628cbe5255ea1679674ac
The rendering code optimizes by rejecting drawing operations that
lie outside of the bounds of their views. This works in most
situations, but breaks down when containers have called
setClipChildren(false), because we reject drawing that is outside
of that container, but which should be drawn anyway.
Fix is to pass in the value of that flag to the DisplayList drawing
routines which take that flag into account when deciding whether
to quickReject any particular operation.
Issue #8659277 animation clipping
Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
bug:8649215
Previously we prevented ops with non-translate transforms from
merging, but missed the case of the first op in a merging batch
containing a non-translate transform.
This fulfills the assumption of drawText's non-immediate mode that
merged ops will have pure translate transforms.
Change-Id: I6f6db341aff3f7e84e74b4c3ccf970d585a2db1a
A clipped saveLayer will cause two draws - first to an onscreen
buffer, then again back to the framebuffer. This change - when in
overdraw debug - reissues draws associated with a clipped saveLayer,
but only to the stencil buffer. Operations within a saveLayer are
shown correctly to be twice drawn, and View.setAlpha() without an
associated hardware layer, or hasOverlappingRendering() are made more
visible.
Hardware layers, on any frame that they are updated, similarly draw
twice, and will also be counted against the stencil buffer doubly.
Note: greater depths of layers - e.g. a saveLayer within a saveLayer -
are not respected, as that would require additional region tracking.
Change-Id: I61fb0e61038fe66013d59914c20bb47a550dea7d
Merge simple bitmap draw operations and text operations to avoid
issuing individual gl draws for each operation. Merging other ops to
be done eventually.
The methods are different - the bitmap merging generates a single
mesh for reused, unclipped images (esp. repeated images in a listview)
The text approach queries just defers the normal font rendering until
the last drawText in the sequence that can share the same shader.
Patches are sorted and merged, but don't yet have a multiDraw
implementation. For now, the pretending-to-merge gives better sorting
behavior by keeping similar patches together.
Change-Id: Ic300cdab0a53814cf7b09c58bf54b1bf0f58ccd6
PBOs (Pixel Buffer Objects) can be used on OpenGL ES 3.0 to perform
asynchronous texture uploads to free up the CPU. This change does not
enable the use of PBOs unless a specific property is set (Adreno drivers
have issues with PBOs at the moment, Mali drivers work just fine.)
This change also cleans up Font/FontRenderer a little bit and improves
performance of drop shadows generations by using memcpy() instead of
a manual byte-by-byte copy.
On GL ES 2.0 devices, or when PBOs are disabled, a PixelBuffer instance
behaves like a simple byte array. The extra APIs introduced for PBOs
(map/unmap and bind/unbind) are pretty much no-ops for CPU pixel
buffers and won't introduce any significant overhead.
This change also fixes a bug with text drop shadows: if the drop
shadow is larger than the max texture size, the renderer would leave
the GL context in a bad state and generate 0x501 errors. This change
simply skips drop shadows if they are too large.
Change-Id: I2700aadb0c6093431dc5dee3d587d689190c4e23
The last frame of an animation stays stuck on the screen for a couple of frames.
Specifically, the "Quick Contact" animation that animates the picture
closed (fades/scales it away) animates all the way to the end... then hangs there
briefly before being taken down.
The problem is a rendering bug where we correctly detect that a DisplayList
has nothing to draw (since the last frame is completely transparent, alpha==0),
but incorrectly ignore the fact that we cleared the transparent-background
window prior to not-drawing that DisplayList. When we detect that there's
nothing to draw, we don't bother swapping buffers. So even though we drew
the right thing (clearing the buffer), we didn't actually post the buffer to the
screen.
This change factors in both the clear and the draw to decide when to swap buffers.
Issue #8564865 Quick contact close animation jank redux
Change-Id: Ib922cff88a94f025b62f7461c1a29e96fe454838
This is a more elegant way to sample from a float alpha texture.
Instead of sampling from the red channel in the fragment shader
we can set the alpha channel swizzle to redirect it to the
red channel. This lets us sample from the alpha channel in the
fragment shader and get the correct value.
Change-Id: I95bbf7a82964e1bf42c0fee1b782b6bdbbcef618
