Bug #3299324
This is needed for ADT, which does not rely on Skia's reference counting
to correctly keep track of the native objects.
Change-Id: Ia2fc5c1ec2b80bad226bc549fefc6bb064784609
The second argument of the JavaPixelAllocator constructor was
eliminated by an earlier change but the class definition was not
updated to match that edit.
Change-Id: I27af0cc52c748cfdec02eb4edcf512dd13f72567
SkBitmap::getPixels() can return NULL. The rest of the JNI Bitmap
code treats this NULL as if the SkBitmap has transparent black
pixels. Bitmap_writeToParcel now does the same.
Change-Id: I5e70b42b3d22a8aea898ce342e590000325bd0f9
The asset system and supporting libraries were using off_t instead of
off64_t to access files larger than 2GB (32-bit signed). This change
replaces all off_t with off64_t and lseek64.
There is a new utils/Compat.h added for Mac OS compatibility.
Also fixed some size-related compiler warnings.
Bug: 3205336
Change-Id: I9097b3cb7a602e811fe52f245939d8975da55e9e
The new field allows a developer to use a more accurate by
slightly slower IDCT method in JPEG decode. This in turns improves the
quality of the reconstructed image.
The field by default is not set and thus does not affect existing
applications.
Bug: 3238925
Change-Id: I93d55b7226e47a43e639325cd1a677694d6f2ee4
Bug #3179882
Resources were freed following garbage collections on a worker thread.
This worker thread had no EGL context, which would cause the renderer
to incorrectly assume that the memory was liberated.
Change-Id: Ifdb51f94ddf42641e8654522787bfac532976c7c
Currently, if a caller specifies both "purgeable" and "just decode
bounds" options when passing a byte array to decode, we create an
unnecessary copy of the byte array. This is probably not common,
but we may as well avoid the copy.
Change-Id: I27e573b0e1fb8f8516729882a84efa02b6da08a5
We now use a copy of SkPaint objects to avoid having it changed from under us.
We reuse copies that have not changed. We also copy the SkMatrix every time to
avoid the same problem.
Change-Id: If3fd80698f2d43ea16d23302063e0fd8d0549027
Native resources (bitmaps, matrices, paints, shaders) are shared when display lists
are used, and a refcounting system is in place to take care of disposing when all
clients are finished with them. But the cache where these refcounts are tracked is
not enabled when the Open GL renderer is not being used. This results in the native
destructors not being called, and the resources are leaked.
Change-Id: Ic7aeb55e4636dcad229846601407e596160346e6
This also removes android.graphics.utils.BoundaryPatch
which was only used by the Browser for the unused drag
tracking (and by a demo app that I'm also removing).
Change-Id: I48253ae005ab11cb4c70d132bc1ea4f2692e2bd2
Fixed issued in ViewGroup's transformation of MotionEvents to ensure
that the entire historical trace is transformed, not just the current
pointer.
Simplified the code in ViewGroup for splitting events across Views.
The new code also handles the case where some pointers are dispatched
to the ViewGroup in addition to its children whereas the previous
code would drop some pointers on the floor.
Change-Id: I56ac31903e1de8a9c376d9c935b7217b0c42d93e
1. Rename LargeBitmap to BitmapRegionDecoder
2. Move the instantiations of BitmapRegionDecoder out of BitmapFactory.
3. Remove the use of MemoryFile in BitmapRegionDecoder, since MemoryFile's API had been modified in master. Otherwise, the change will break the master build.
4. Move AssetStreamAdaptor, AutoFDSeek and nullObjectReturn to Utils.h because BitmapFactory.cpp and BitmapRegionDecoder.cpp both need to use these utility functions.
Most of the modifications, except for (2) and (3), were reviewed in https://android-git.corp.google.com/g/#change,64716 .
However, that change broke the master build due to (3) and was reverted eventually.
So, instead of withdrawing this change and waiting for that change to be checked in again, I merge the two changes into one.
Change-Id: I2202c0fbbbd6d6676bbd9637e690023ea4099c40
This change also adds full support for local transformation matrices on
sweep and radial gradients.
Change-Id: Id8773bc0766575190e3f3d51984fc5e57b266c3f
In nativeCreateLargeBitmapFromFileDescriptor() if the file descriptor
can not be rewinded isShareable should be set to false.
Change-Id: I7dd545c9d52d21c226e11b8921e35a1d9bba9515
Merge commit '8fc6f8b2152564cab6ede025644f9bc3ee61ce16'
* commit '8fc6f8b2152564cab6ede025644f9bc3ee61ce16':
Revert "Rename LargeBitmap to BitmapRegionDecoder for having a better API."
Merge commit 'a295a3908befeb9dd30203c612d95411d68492ed'
* commit 'a295a3908befeb9dd30203c612d95411d68492ed':
Rename LargeBitmap to BitmapRegionDecoder for having a better API.
Working on speeding up our NIO implementation, I came across this suboptimal
code. Happily, it turns out to be unused.
Bug: 2935622
Change-Id: I07ae6e573d63e439f496d55af215b34598d8258a
Move AssetStreamAdaptor, AutoFDSeek and nullObjectReturn to Utils.h because
BitmapFactory.cpp and BitmapRegionDecoder.cpp both need to use these utility functions.
Change-Id: I3e60c7fe4abd0289e1384e69a08fd20fe6fb0e10
Merge commit '9f7257f0a14cd17d8b55bc3bd1584dac2f9dd1b2'
* commit '9f7257f0a14cd17d8b55bc3bd1584dac2f9dd1b2':
Fix a bug, where one thread is using JNIEnv associated with another thread.
Before this change, all framework assets would be decoded at drawing time
outside of zygote. This was forcing all apps to re-decode the assets and
zygote to keep an in-memory copy of each asset. This behavior is now
opt-in by setting the inPurgeable flag on BitmapFactory.Options.
Change-Id: Ief823139163d8071b8ee1267746622faf52eb8ec
Before this change, all framework assets would be decoded at drawing time
outside of zygote. This was forcing all apps to re-decode the assets and
zygote to keep an in-memory copy of each asset. This behavior is now
opt-in by setting the inPurgeable flag on BitmapFactory.Options.
Change-Id: Ic703f57adb26b2a701ecff0a653d35a93e26d47c
We see abort messages like this when using JavaPixelAllocator and JavaMemoryUsageReporter.
W/dalvikvm( 680): JNI WARNING: threadid=2 using env from threadid=10
W/dalvikvm( 680): in Landroid/graphics/LargeBitmap;.nativeClean (I)V (CallVoidMethodV)
To fix it, we keep JavaVM, rather than JNIEnv, in JavaPixelAllocator and JavaMemoryUsageReporter,
because JavaVM allows us to get the JNIEnv corresponds to the current thread.
Change-Id: Ibd4b394a53dd3fdccc5a442eeb0dedf836479575
