Bug: 26498479
Although the size of struct ScriptCall is not used underneath in the
runtime or drivers, assign the correct value here to avoid confusion.
Change-Id: I8db19538b9f70f3bf9ee849a8724da3d9ee04785
http://b/27251511
Handle FLOAT_16 case to PER_ARRAY_TYPE macro to enable untyped variants
of Allocation-copy functions.
Untyped variants of Allocation-copy functions call
validateObjectIsPrimitiveArray(), with checkType parameter set to true,
to validate and obtain the Element type of the Allocation. When
checkType is true, validateObjectIsPrimitiveArray() returns the actual
Element type of the Allocation (instead of the canonical SIGNED type).
Because of this, FLOAT_16 element type can reach the JNI layer,
necessitating this change to PER_ARRAY_TYPE macro.
Change-Id: I3651e5ae0ab0cd6bb4ad3157841e2910ac8699dc
(cherry picked from commit 85e8c51dbf8dc774ecfd09981ac6a8bf1b75f464)
Bug: 25570907
Added a flag to all RS runtime API for rsObj creation to indicate a
call is from Java. This flag will help us avoid incrementing the user
ref count for rsObj's created from Single-Source RS, and therefore
avoid memory leaks for such objects.
Change-Id: Id3604f93b166089e3aca896d1c6c509b3ea19bcf
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
