Avoid to access invalid index in CacheBitmap. That will cause the android SDK image cannot be booted up
with H/W GL enabling. This patch is required by both ARM and x86 SDK system image.
Change-Id: I705b7f06915a2338a2f94509486344bfd92b4bfb
Signed-off-by: Jun Tian <jun.j.tian@intel.com>
Signed-off-by: Jackie Wu <jackie.wu@intel.com>
Signed-off-by: Liang Chen <liang.l.chen@intel.com>
Signed-off-by: Panfeng Chang <panfengx.chang@intel.com>
Bug #6836448
External bug: http://code.google.com/p/android/issues/detail?id=34946
DO NOT MERGE
DisplayListRenderer::drawPath was not invoking quickReject() properly,
passing x,y,width,height instead of left,top,right,bottom. A path
could thus get rejected when it should be drawn instead.
While working on this change I found a similar issue with another
drawing command, drawBitmapData().
Change-Id: I8306faf72db14d71b54ecb7de295c9a6957d9494
DO NOT MERGE
External bug: http://code.google.com/p/android/issues/detail?id=34879
This is a regression from ICS.
This CL also fixes a bug where a View's alpha would be applied twice.
Change-Id: I13a1546228f44d4c169259414b6fa103a6e4a0fa
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
A previous fix made it necessary for a frame to render something to GL
in order to cause a call to eglSwapBuffers(). Besides the calls being
tracked as part of issuing a DisplayList, there is also a potential call
to clear the canvas (via glClear()) on non-opaque surfaces. This call is also
good to track, since a surface that gets cleared without any other drawing operations
is worth flipping to the screen (to erase old contents on that surface).
This fix tracks the status of the pre-draw operations to find out whether
glClear() was called and then sets the drawing status appropriately.
Issue #6606422 QuickContact dismissal is janky again (Tracking)
Change-Id: I5fcaccfdc9293dd46b83f2fc279730a5d2740ebf
The fix is to track when we issue GL drawing commands, and to skip the
call to eglSwapBuffers() when a DisplayList does not result in
any actual rendering calls to GL.
Issue #6364143 QuickMuni list items and buttons flicker instead of fade
Change-Id: I60a02c61a58c32d92481a1e814b4c8a49c6a37a3
This also removes the temporary logging from commit
f8dafa14e058cdc2f408b59be7911abaceb73c47.
bug:6535911
Change-Id: Icf1d0438b349a0e92e7d9cefed57a252eed2b9b0
Bug #6527305
At the beginning of a frame, always set the blending mode that we
think GL is using just in case it was modified by another entity
(for instance a WebView functor.)
Change-Id: I0e1d0abee8a2abb2b8e7622aed28346e89562c06
The comparisons used in the various properties setters could fail badly
in some specific conditions. The scale properties in particular did not
use the same comparisons.
This change also clamps alpha to the 0..1 range which avoids overflow
issues with lowp registers in GLSL computations.
Change-Id: I3e73b584e907a14e2c33d0865ca0d2d4d5bff31d
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
Some logic in the native matrix code would determine that a matrix was
'pureTranslate' based on the scale values of a matrix being close-enough to 1,
which was within a very small epsilon. This works in general, because screen space
coordinates make that epsilon value irrelevant, so close-enough really is close-enough.
However, TextView, when centering text, works in a coordinate system that is quite
huge, with left/right values about 500,000. These numbers multiplied times that small
epsilon value would give a result that was significant, and would cause a miscalculation
of up to 4-5 pixels, causing the snap that we'd see for a couple of frames as the
scale got "close enough" to 1.
The fix is to remove the optimization of "close enough". What we really need the matrix to
do is to identify itself as being translate-only when no scale as been set (which is the
default). For the purposes of that check, it is good enough to simply check the values against
1 directly. Similarly, the bounds-check logic needs to check against 0 and 1 directly.
Issue #6452687: Glitch when changing scale of a view containing text
Change-Id: I167fb45d02201fb879deea0e5a7ca95e38128e17
An optimization for paths is to only create a texture for the original native
Path object, and have all copies of that object use that texture. This works in
most cases, but sometimes that original path object may get destroyed (when the
SDK path object is finalized) while we are still referencing and using that object
in the DisplayList code. This causes undefined errors such as crashes and hanging
as we iterate through the operations of a destroyed (and garbage-filled) path object.
The fix is to use the existing ResourceCache to refcount the original path until
we are done with it.
Issue #6414050 Analytics Dogfood App crashes reliably on Jellybean
Change-Id: I5dbec5c069f7d6a1e68c13424f454976a7d188e9
There was a bug in the DisplayList code for layers where we would
set the alpha value for a layer only if the alpha were non-1. This works
most of the time (since the value is usually 1 and doesn't need to
be set at all, and if the value is non-1, it is set correctly). But when
the value has been set to a non-1 value, setting alpha back to 1 cannot happen
due to this logic. This caused launcher to have some invisible pages when
returning to Home because those pages previously had an alpha value of 0, and
setting the alpha to 1 had no effect due to this DisplayList code.
The fix is to simply remove the check for non-1 values; we should
always set the alpha value of layers to handle all cases.
Issue #6413892 alpha value is messed up after AlphaAnimation
Change-Id: Ia51acb2eaaf0609ea7189998ed449bdd9ea7e05f
Bug #6411457
Skia does not generates the bottom right pixel of a rect when
drawing a rect as an SkPath into an alpha8 bitmap.
Change-Id: Ifb5286ae67745c9e44ee387b6d6ad607a9a2e6ce
Bug #6365056
WebView enqueues a functor in the hardware renderer to handle
animations and this functor is called at a later time by the
hardware renderer. However, the functor was not removed from
the queue when WebView was removed from the window. This could
cause the hardware renderer to attempt to execute an invalid
functor and lead to a crash.
Change-Id: I9d38e80f3fdc5e29d4d0cdfa1e893c251a954508
This flag was still hanging around pending any need to disable
DisplayList properties. But things seem stable, so it's time to clean up
and simplify the code.
At the same time, I reduced redundance in DisplayList dimensions. We
used to call drawDisplayList() with width/height parameters that were
used to do a clip reject. This is redundant with the DisplayList properties
that set the bounds of the DisplayList; the left/right and top/bottom properties
represent the same width/height properties formerly used in drawDisplayList().
The new approach is to not pass dimensions to drawDisplayList(), but to
instead pull those dimensions directly from the DisplayList when needed.
Change-Id: I8871beff03b1d4be95f7c6e079c31a71d31e0c56
Cached layers were sometimes retaining an obsolete blending
value, causing artifacts where translucent objects were disappearing
completely. Also, added extra tracing info for DisplayLists.
Issue #6303668 Flickering views during SwipeHelper drag
Change-Id: I66ce158652c4a3ed316040585b40b1744e1fad0c
When webview draws into an fbo layer, it needs to know the
size of that surface to create the rendering transform appropriately.
This change copies in the current viewport size to the structure that
is passed to the webview.
Change-Id: I7160b0836d00834134c799c95a439cdc045e2035
Some views (such as ImageView and TextView) handle non-opaque alpha
values directly. This was originally an optimization, but we can handle it faster
in many cases without this optimization when DisplayList properties are enabled.
Basically, if a view has non-overlapping rendering, we set the alpha value directly
on the renderer (the equivalent of setting it on the Paint object) and draw each
primitive with that alpha value. Doing it this way avoids re-creating DisplayLists
while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties.
Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
