bug:10863163
This fixes two issues
The check for pure translation was incorrect. It was fixed and renamed
for clarity.
Certain matrix paths weren't setting kTypePositiveScale. For
simplicity (and because positive scale is simple to check) removed
flag in favor of dynamic checking.
Change-Id: Ic5ce235653ef49a68b8b242bd89fc2e95874ecc9
bug:10761696
Avoids a case where a rect with top coordinate of (e.g.) 0.51f is
assumed to not draw in the first row of pixels, which leads to it not
being clipped. Since rounding can cause it to render in this first
pixel anyway, we very slightly expand geometry bounds.
Now, in ambiguous cases, the geometry bounds are expanded so clipping
is more likely to happen.
Change-Id: I119b7c7720de07bac1634549724ffb63935567fc
Bug: 10677765
enableScissor() must precede setScissorFromClip() as
otherwise setScissorFromClip() doesn't do anything.
Also make sure to call setScissorFromClip() if
enableScissor() returns true as enableScissor() calls
resetScissor() if the scissor state has changed.
Change-Id: I9226b20bb256c92066aae344e4e6407540b6eae9
Also remove dead code from OpenGLRenderer.cpp
Change-Id: I7eb54ca19e77ee3c32f1fe9513a031e6b2e115cf
(cherry picked from commit 5c7d5ab878b26f855175a3305a14ac12fcacf25e)
By having quickReject round out the window-space geometry bounds, we
prevent the AA perimeter (which falls outside the local bounds passed
in) from drawing outside the clip.
Change-Id: I8ee36be9039a9c47906815ee2f0dbaa5eb910b82
Quite a few things going on in this commit:
- Enable bitmap strikes by default in Paint objects.
The SkPaint parameter that enables bitmap strikes was not previously
included in DEFAULT_PAINT_FLAGS. This effectively disabled bitmap
fonts. Oops! It's for the best, though, as additional work was needed
in Skia to make bitmap fonts work anyway.
- Complain if TEXTURE_BORDER_SIZE is not 1.
Our glyph cache code does not currently handle any value other than 1
here, including zero. I've added a little C preprocessor check to
prevent future engineers (including especially future-me) from
thinking that they can change this value without updating the related
code.
- Add GL_RGBA support to hwui's FontRenderer and friends
This also happened to involve some refactoring for convenience and
cleanliness.
Bug: 9577689
Change-Id: I0abd1e5a0d6623106247fb6421787e2c2f2ea19c
An array of indices local to a layer would only be necessary if
we changed the way we resolve T-junctions. Since we only ever
draw quads, let's just use the indices we use everywhere else.
This change also uses the global indices array to render list
of colored rectangles to save on the number of vertices generated
CPU-side.
Change-Id: Ia6d1970b0e9247805af5a114ca2a84b5d0b7c282
Bug #9425270
A better solution would be to use glCopyTexImage2D whenever possible but
this change would be a little more dangerous.
Change-Id: Ib1aaceda39d838716285ef97f356721416822dbb
Bug #9589379
If the atlas is terminated/reinitialized and a view does not invalidate
in between it might end up using a stale AssetAtlas::Entry. This change
is similar to how 9patch meshes are cached in DrawPatchOp: we simply
track the generation ID of the cache to make sure we always use the
latest data.
Change-Id: Ib5abb3769d2ce0eabe9adc04e320ca27c422019e
This allows merged, clipped operations to behave correctly within a
savelayer, even if the base viewport has a large offset.
Additionally, disregard opaqueness when within a
complexclip/savelayer, as the coverage can't be trusted.
Change-Id: Ic908b82a4bb410bc7fac1b4295f4874ed166efc5
This change also fixes the way batched bitmaps were handled
inside a layer. The layer is now correctly dirtied to minimize
the amount of pixels to blend.
Fix alpha, mode and opaque computations for DrawPatchOp.
Change-Id: I1b6cd581c0f0db66c1002bb4fb1a9811e55bfa78
This reduces state changes when we draw 9patches and text together,
which happens *a lot*. Also disable the NV profiling extension by
default since it doesn't play nice with display lists deferrals.
To enable it set debug.hwui.nv_profiling to true.
Change-Id: I518b44b7d294e5def10c78911ceb9f01ae401609
bug:9464358
Previously, empty and unknown sized ops are assumed to fully cover
their clip. This is now corrected such that empty sized ops are
pre-rejected before defer. Additionally, unknown sized ops disable
overdraw avoidance.
Change-Id: Icf2ce24f98be5ea6299e24ffcf826790373564a1
Previously, a new op with a clipped side could be added to a
MergingDrawBatch without considering the batch's current bounds.
Change-Id: I1b873ecf821bad7cda6630c3f311edd90ac5cc8c
bug:8965976
Also consolidates quickReject scissor-ing and scissor-less paths.
Renamed plain 'quickReject' method, as it has sideEffects beyond what
the java and skia canvases do.
Change-Id: I4bdf874d3c8f469d283eae1e71c5e7ea53d47016
bug:8951267
If an opaque op, or group of opaque ops covers the invalidate region,
skip draw operations that precede it.
Clipped operations may now be merged, but only if they share a
clipRect - this is a very case for e.g. ListView, where all background
elements may now be a part of the same MergingDrawBatch.
It is this more aggressive merging that groups together clipped
background elements in the ListView case, enabling the overdraw
avoidance skipping the window background.
Change-Id: Ib0961977e272c5ac37f59e4c67d828467422d259
This optimization saves up to 0.3ms per frame on the Play Store's
front page, on a Nexus 4 device.
Change-Id: Iaa4ef33c6e3b37e175efd5b9eea9ef59b43f14f3
The virtual textures would each have their own values for wrapping
and filtering which could lead to conflict and/or extraneous GL
commands being issued.
Change-Id: I64cb59a03e598f46bf645bd1d30fccfa63a07431
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
bug:4351353
bug:8185479
Point tessellation is similar to line special case, except that we
only tessellate one point (as a circle or rect) and duplicate it
across other instances.
Additionally:
Fixes square caps for AA=false lines
Cleanup in CanvasCompare, disabling interpolation on zoomed-in
comparison view
Change-Id: I0756fcc4b20f77878fed0d8057297c80e82ed9dc
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
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
