Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
The opacity calculation for a gradient drawable of shape must take
rounded corners into account - if the corner radius is nonzero, then the
shape is translucent rather than opaque. Previously the code always
assumed that such rectangles were fully opaque, which led to the
background (visible behind the rectangle) not getting drawn.
This patch simply checks for corner radius in addition to shape and
computes opacity as translucent in the nonzero case.
Change-Id: Iaf4d24abc6ecf49f85c82972b8f998700c83295e
A change in the VM triggers a native memory error more aggressively than before,
showing that there's a bug in the logic of recycling bitmaps. Since the pixel
memory is allocated on the Java heap, nulling out the reference to that memory
in the Java level Bitmap object can cause that memory to get collected at any time.
Meanwhile, we may have a reference to that memory at the native level for rendering
purposes, causing an error if/when we access that memory after it has been collected
by the VM.
The fix is to avoid setting the reference to the pixels to null unless we are
not referring to it in native code. This is determined at the time we call
recycle() - we return a boolean to indicate whether the native code is still
using the memory. if not, the Java code can null out the reference and allow the
VM to collect it. Otherwise, it will get collected later when the encompassing
Bitmap object is collected.
Issue #7339156 HTML5 tests crash the app (Vellamo)
Change-Id: I3a0d6b9a6c5dd3b86cc2b0ff7719007e774b5e3c
Bug #7353771
This API can be used when scaling large images down to a small size
to get nicer looking results.
Change-Id: If09087eed36077eee5355f6047a3ca67747d7d9e
Intrinsics were treating inputs as fields rather than varObjs.
This would generate a lot of extra work for the reflection
layers. Also we would like to deprecate this path in the future.
bug 7318821
Change-Id: I81e8c562ba05aae5d085d5c08e91e2c4877265c5
Make Bitmap.copyPixelsFromBuffer() adjust the buffer's position,
making it consistent with Bitmap.copyPixelsToBuffer().
b/6948775
Change-Id: Ie26f8050b1fb4d19cd39ee1a08b6f652a732fec3
Bug #7275145
This change fixes ViewRoot and adds extra debug information. It does
not solve the problem entirely. Another CL will.
Change-Id: I7e604ba38aad7f421769783dcbd998d6905ab2d9
Bug #7274157
Gradients and color filters are multiplied by the paint's color so it
needs to be set to opaque black to have an effect.
Change-Id: Ib5dd1e6185f758f55b57a0f4496dfae98f1a096b
The intrinsic fails when the radius was 0. A blur
of radius 0 is a nop and should be disallowed. Fix the
test to allow sub-pixel radius to be selected.
bug 7273437
Change-Id: I2805674e29d557615eb7ac65c7910d4dffa28b58
Bug #7233734
Stroked rectangles were rendered using software generated textures
which would lead to slightly misaligned results. Instead, let's use
the new convex path rendering code that will do the right thing
(and save a lot of bandwidth.)
Change-Id: Ib95ff581e56c1ecead97e4919298e6fd146ca167
This CL generalizes the optical bounds support previously contained in the
GridLayout implementation and then incorporates the new form directly into
the base View and ViewGroup implementations. After this change, GridLayout is
returned to an 'optical bounds' unaware state, and all layouts (including non-platform
ones) inherit the ability to perform their layout operation by optical (rather than clip)
bounds using their existing implementations.
The "layoutMode" property of ViewGroup and its associated constants are
made public in this CL.
Change-Id: Ic1bba0e1c6fc14da4aeab0b28c975d562b5f82dd
This prevents issues where one thread recycles the decoder while another
thread is in the process of checking the decoder's status or in the process
of decoding a region.
bug: 6880937
Change-Id: I7f755bf2149d03594e528ca79c536713b1447a55
