Only performs the GL setup steps when at least one glyph is drawn.
This change also skips various draw operations when the specified
paint draws with alpha = 0.
Change-Id: I9eda148b0503acffc552ee19196f5d52e958a1a2
This change moves the mesh buffer from FontRenderer to CacheTexture
to help reduce the number of texture binds and glDraw calls when
drawing text that spans across multiple textures.
Change-Id: I7de574d88313ca3672879ca878c253ff5f131fc1
When several CacheTextures are used to draw text, sort the
draw batches by texture ID to minimize state changes in the
driver.
This change also tweaks the font cache size and renames
a property that was too long to be set using setprop.
Change-Id: I0a36dfffe58c9e75dd7384592d3343c192d042b1
Fonts are now described by a transform matrix. This lead to switching
from a vector to a hashmap. This change therefore adds new comparators
and hash computations to Font.
Change-Id: I2daffa7d6287c18554c606b8bfa06640d28b4530
Previously, cache textures were updated whenever mCurrentCacheTexuture was changed.
Since updating cache textures needs glTexSubImage2D call, frequent changing
of mCurrentCacheTexture (which can easily happen when an app uses lots of unique glyphs
even with precaching) caused many glTexSubImage2D calls and bad framerates.
This patch optimized isssueDrawCommand function. Consequently, changing mCurrentCacheTexture doesn't
cause glTexSubImage2D call any more and it will improve font rendering performance.
Change-Id: Id19d959fa0e69eeb2a39f83a57e311d7394586b2
Signed-off-by: Sangkyu Lee <geteuid@gmail.com>
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
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
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
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 #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
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
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
This optimization is currently disabled until Launcher is
modified to take advantage of it. The optimization can be
enabled by turning on RENDER_LAYERS_AS_REGIONS in the
OpenGLRenderer.h file.
Change-Id: I2fdf59d0f4dc690a3d7f712173ab8db3848b27b1
