bug:4419017
bug:7230005
- Adds support for stroke/strokeAndFill for shapes without joins
- Fixes path-polygonization threshold calculation
- Fixes rendering offset (now only used for points)
- Several formatting fixes
Change-Id: If72473dc881e45752e2ec212d0dcd1e3f97979ea
Only upload the changed area of the glyph cache, not the entire
bitmap. Note that we can't do the full-on optimization here of copying a sub-rect
of the bitmap because of GL ES 2 limitations, but we can at least copy the
horizontal stripe containing the dirty rect, which can still be a big
savings over uploading the entire bitmap.
Issue #7158326 Bad framerates on MR1 (Mako, Manta, Prime)
Change-Id: Iab38d53202650f757ead4658cf4287bdad2b3cb9
FontRenderer.h defined several classes and structures that now live
in the font/ folder. This will make the code easier to read and
maintain.
Change-Id: I3dc044e9bde1d6515f8704f5c72462877d279fe2
Add new parameters for the texture size used for the larger, fallback caches.
Bump up the defaults in some situations.
Issue #7045164 Adjust cache sizes for manta
Change-Id: I562118ce785d7f8b6e445178878672e9709d25f2
It is unlikely, but possible, to draw so many glyphs in a frame
(especially of the glyphs are quite large) that the cache starts flushing
itself to fit the later glyphs in. This causes unnecessary thrashing, because
when we actually draw the frame, we will again need to flush to fit the
earlier glyphs in, and then flush again to fit the later ones in.
It is better to avoid thrashing the cache at the precache phase, and wait
until we actually draw the glyphs that do not fit to do any eviction of
the earlier glyphs.
This change simply notes when we are in the preaching phase, and avoids flushing
the cache when a glyph does not fit.
Issue #7081725 avoid thrashing cache during DisplayList recording
Change-Id: I230410ab5b478091b1032fa99dc1752acf868bbe
Glyphs were being stored in the glyph cache incorrectly.
The second row of glyphs in any column were being positioned exactly
one pixel too high, causing the preceding glyph in that column to be
cropped, resulting in the reported truncation in some glyphs.
Issue #7003215 Minor UI truncation while reading the mails
Change-Id: I47ce376f78a04d4e07e8b7ed1b3f0b58864c5498
CacheTextureLine was useful before we were packing the glyph
textures; it allowed simple packing of any particular texture according to
how many lines there were in a texture, and how tall those lines were.
Now that we are packing more efficiently (both horizontally and vertically
in any given texture line), it is more efficient to have
open space in every texture, removing the need for CacheTextureLine (which
now gets in the way since it limits how much can be stored in each line).
This change removes CacheTextureLine and just uses CacheTexture directly,
allowing caching of glyphs anywhere in the open space of each texture. As before,
the packing of these glyphs is determined by the CacheBlock structure, which
is a linked list of open spaces in each CacheTexture.
Change-Id: Id6f628170df0f676f8743ac7de76f2377fc6a012
Precaching at startup was not working. One-liner fix to init the caches
so that precaching would kick in earlier, saving time at startup by avoiding
the multiple-upload issue of caching at render time.
Issue #6893691 long app launch time on manta for some apps comparing to nakasi/stingray
Change-Id: Ie5c7f0536ec8ea371c7892e5e09c1db14795531c
There are two fixes here:
- precaching: instead of caching-then-drawing whenever there is a new
glyph, we cache at DisplayList record time. Then when we finally draw that
DisplayList, we just upload the affected texture(s) once, instead of once
per change. This is a huge savings in upload time, especially when there are
larger glyphs being used by the app.
- packing: Previously, glyphs would line up horizontally on each cache line, leaving
potentially tons of space vertically, especially when smaller glyphs got put into cache
lines intended for large glyphs (which can happen when an app uses lots of unique
glyphs, a common case with, for example, chinese/japanese/korean languages). The new
approach packs glyphs vertically as well as horizontally to use the space more efficiently
and provide space for more glyphs in these situations.
Change-Id: I84338aa25db208c7bf13f3f92b4d05ed40c33527
Bug #6942209
The font renderer was preserving a 1 px border around each glyph to ensure
bilinear filtering would work nicely. Unfortunately, this border was not
set to 0 when glyphs were added in the cache to replace old evicted glyphs.
Change-Id: Ib85afca7ebad5cb63f960dc0e87ae162333dbfe8
This patch adds support for drop shadows (setShadowLayer) for
drawPosText in the hwui renderer. In and of itself, it's not very
important, but it's on the critical path for correct mark positioning,
tracked as bug 5443796.
The change itself is fairly straightforward - it basically just adds an
extra "positions" argument to all draw and measure methods on the code
path for drawing drop shadowed text, as well as to the cache key for
cached shadow textures.
Change-Id: Ic1cb63299ba61ccbef31779459ecb82aa4a5e672
Bug #6597730
Text would sometimes not appear when rendered with textured content
(BitmapShader, LinearGradientShader, etc.) This was due to a misuse
of OpenGL texture unit in FontRenderer. Textured text normally uses
two texture units:
- texture unit 0 for the font cache
- texture unit 1 for the textured content (gradient, etc.)
Recent changes to the font renderer allow it to bind new textures
while processing the text's geometry (this happens when caches get
full or when switching font size for instance.) The bindings were
done without ensuring the texture unit was the correct one
(unit 0), thus replacing the content of another texture unit
(unit 1).
This lead to text being drawn using the font cache itself as the
content texture, making the text invisible.
Change-Id: I392b4c884f09223305f6cbc6253e2ef9a98944c9
Bug #6408362
FontRenderer allocates large font textures when more room is needed
to store all the glyphs used by an application. Thse large textures
are the first to be freed when memory needs to be reclaimed by the
system. When freeing a texture, the renderer would however not set
the texture name to an invalid name, leading future allocations to
be performed on the same texture name. That name could have by then
be recycled by the driver and returned by a call to glGenTexture
and used to create an entirely different texture. This would cause
the font renderer to point to the wrong texture, thus leading to
the "corruptions."
Change-Id: I8a1e80e5b79e8f21d1baf5320c090df4f2066cd4
WebView needs more fine-grained control over the behavior of the
framework upon execution of the display lists. The new status_t
allows WebView to requests its functor to be re-executed directly
without causing a redraw of the entire hierarchy.
Change-Id: I97a8141dc5c6eeb6805b6024cc1e76fce07d24cc
Bug #6196903
Whenever a memory flush happens, the GL renderer discards some or all of its
font caches. Each font cache holds an array of vertex indices that was
initially designed to have the same life cycle as the process. This changed
when memory flushes were introduced but this array was never taken care of
in the destructor.
Change-Id: Ief124f609ea55b671c0a9b43637d9e013629ebaa
Currently, font renderers eliminate some texture caches when
memory is trimmed. This change makes it go further by eliminating the
large-glyph caches for all font renderers. These caches are
only allocated as needed, but continue to consume large amounts of
memory (CPU and GPU) after that allocation. De-allocating this memory
on a trim operation should prevent background apps from holding onto
this memory in the possible case that they have allocated it by drawing
large glyphs.
Change-Id: Id7a3ab49b244e036b442d87252fb40aeca8fdb26
There were 2 issues remaining after a recent change to support
glyph caching from multiple textures:
- memory in the GPU for all textures was being allocated automatically.
This is now lazy, being allocated only when those textures are first
needed.
- filtering (applied when a rendered object is transformed) was ignoring
the new multiple-texture structure. Filtering should be applied correctly
whenever we change textures.
Change-Id: I5c8eb8d46c73cd01782a353fc79b11cacc2146ab
Some GPU architectures could not handle the previous implementation
of our glyph cache. Frequent uploads would cause memory problems in the GPU
and eventually a crash due to these memory issues. The solution is to move to
a system of several, smaller caches instead of one monolythic cache for all
glyphs.
Change-Id: I0fc7a323360940d16d5a33eeb33abfab194c5920
This optimization along with the previous one lets us render an
application like Gmail using only 30% of the number of GL commands
previously required
Change-Id: Ifee63edaf495e04490b5abd5433bb9a07bc327a8
Bug #5659476
The FontRenderer was not cleaning up its temporary state, leading
to crashes when invoking renderDropShadow.
Change-Id: I43b24820dd5625af8c080bbe11b64de2f74164b2
Glyphs drawn with paints that had different textScaleX values were not
being recognized as different, so the glyph cache was being used regardless
of different scaleX values. This change adds the scaleX attribute to the native
Font object to allow the cache to distinguish between this difference and cache
accordingly.
Change-Id: I5d8fc26d47460b27dc8e373a473d46b2f1b8dc30
