Bug: 23535524
Two APIs added for multiframe processing:
- createAllocations(...): To create an array of Allocations sharing the
same Type and Usage. For USAGE_IO_INPUT Allocations, they also share
the same BufferQueue.
- getTimeStamp(): API to retrieve the time stamp associated with the
most recent buffer.
Change-Id: I6b7b35d7dca5e87ee2f3db2ee17cb9cf824bcfe1
Bug: 25926361
Bug: 23535524
- Construct the ByteBuffer using the AllocationGetPointer.
- Add an API to query the stride of the allocation.
- Both ByteBuffer and Stride will be cached for normal Allocations.
if using USAGE_IO, since after each ioReceive, the mallocPtr will
change, getByteBuffer will always create a new one using the most
up-to-date mallocPtr.
Change-Id: I5e84b6690e83bb062c383043275524d0e51e46eb
Bug: 25602504
1) Passing floating point values into a script group was broken,
since they were casted to long values. Fixed that in the frameworks
implementation by taking the raw bits instead.
2) Passing 64-bit values into a script group was broken on 32-bit
platforms, since they were casted to pointer-sized integers
(uintptr_t) in the JNI code. Fixed that by casting to int64_t
instead.
3) Setting global variables of Allocation type in a script group was
broken. The special size value -1 was used to indicate the value is an
Allocation. However, size was casted to size_t in the JNI code.
Fixed that by using signed integers.
Change-Id: Ifff099a76be7707df7b67c388395f5a00f9cae66
reduce-style kernel.
Bug: 22631253
This adds a new (currently hidden) API to the Script class and the
corresponding code for the RenderScript JNI layer.
Change-Id: I40f19aaeb90411b859bd6b0bffc3f071fa327c21
Cherry-pick fix from AOSP. Error check for kernel launch was
generating a false positive.
bug 20690242
Change-Id: Ic4c6644072a11aab9a273070be5734519136f685
b/20728113
In case the requested size for memory allocation overflows, or memory
allocation fails.
Change-Id: I8dac132dd4d0210938660ffbb82cbe44000d2a90
(cherry picked from commit 4e90b9b57cc96964a9d5c1845172a72cb51feafb)
b/20728113
In case the requested size for memory allocation overflows, or memory
allocation fails.
Change-Id: I8dac132dd4d0210938660ffbb82cbe44000d2a90
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Attempt #2 to land this, original issue was in getSkBitmap
and should be fixed
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
b/19944127
Also added references to arguments and global values in a closure to
keep them live in Java while native code may access them.
Change-Id: I1179d34aa67f845578740e71cc2da4f82419f251
