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
Make Bitmap.copyPixelsFromBuffer() adjust the buffer's position,
making it consistent with Bitmap.copyPixelsToBuffer().
b/6948775
Change-Id: Ie26f8050b1fb4d19cd39ee1a08b6f652a732fec3
You can setprop debug.hwui.show_layers_updates true to flash
hw layers in green when they update. This is also a setting
in the Dev. section of the settings app.
Change-Id: Ibe1d63a4f81567dc1d590c9b088d2e7505df8abf
Preloaded drawables now have a density associated with them, so we
can load the correct drawable if we are using a different density.
Window manager now formally keeps track of the density for each
screen, allowing it to be overridden like you can already do with
size, and relies on this density to drive itself internally and
the configurations it reports.
There are a new set of Bitmap constructors where you provide a
DisplayMetrics so they can be constructed with the correct density.
(This will be for when you can have different windows in the same
app running at different densities.)
ActivityThread now watches for density changes, and pushes them
to the DENSITY_DEVICE and Bitmap global density values for that
process.
A new am command allows you to change the density.
- Added a new custom PNG chunk that carries the layout padding ints.
- Extract the padding ticks from .9.png images and store in the chunk.
- Load the padding information at runtime into Bitmap and NinePatchDrawable.
- The new chunk is ordered first so that it doesn't cause a problem in older
versions of the platform.
Bug: 6087201
Change-Id: I5de46167a1d44b3ec21065b0c165e594b1dc8399
* Don't call context.getResources() redundantly when unnecessary;
similarly for Resources.getCompatibilityInfo()
* During bitmap creation, don't bother clearing to 0: it's unnecessary
because now that the raw bits are stored in a VM-side byte array, it
was cleared at initialization time. Also, don't use the sanity-
checking public entry point to erase to a color, because we know
that we're by definition in a "legal" path to erase to the initial
contents and don't need to incur the overhead of the (inappropriate)
sanity checking.
Change-Id: Idaca4d64fdecefd5d51337646ead32e1db510e02
This reverts commit 56c58f66b9
This CL was causing the browser to crash when adding bookmarks, visiting the bookmarks page, and sharing pages (see bug http://b/issue?id=5369231
Note: The integrator of this change to Android internal code-repo will
have to run one extra step 'make update-api' to update 'api/current.txt'
file corresponding to approved API. The AOSP branch didn't have this
file, hence I could not add the same to this change. The updated file
'api/current.txt' has to be submitted along with this change.
Change-Id: I29909e907a2e82d801e16654322190a808c5bda9
It looks awful.
Don't use it.
Use ARGB_8888, it's much better.
If you think you need ARGB_4444, you are wrong.
You are.
Change-Id: I4d6963cf98b6a8fb34cebcd0d24b9fd66b5a0fbf
Bug #3408073
Bitmap.setHasAlpha() in particular is very useful for applications that use
ARGB_8888 bitmaps but want/need to benefit from an extra speed boost.
Change-Id: I73d081b7e43bd725baffd1a9892c72d8729816f7
Bug #2988077
This change keeps the 8888 format for new bitmaps and also keeps,
when possible, the opaque flag.
Change-Id: Ia61f2e89936916b329212a4c59a7d815c329f84e
If an object A's finalizer calls Bitmap B's recycle() when B's
finalizer is already called, we will have trouble because the
native bitmap is already freed in the finalizer.
Change-Id: Ic0be8ed75fb3aacee9ce6e3d9908178a55151eb9
This change also removes the use of SoftReferences for View's
drawing cache.
A bitmap now creates a PhantomReference enqueued in a reference
queue provided by the new Finalizers class. This queue is polled
from a thread started after forking zygote. That thread is in charge
of clearing the references after GC runs and of calling reclaim()
on them. The reclaim() method is now how finalizers are run.
Note that a PhantomReference cannot be kept in the instance it
refers to, which is why they are kept in a separate List.
Change-Id: If3c1a5e9dc23fa49e34857860d730f5cf5ad5926
Bitmap.getGenerationId() can be used by caches to find out if a Bitmap has been
modified. This simply exposes an existing Skia API.
This change also adds a small test app for Canvas hardware acceleration. The new
Bitmap API is required to implement a texture cache.
Change-Id: I8547b146cd14c8afe1a2327fcd6d71b1b1cb68fc
An issue with the density API is that bitmaps assumed the old default density,
so new programs would have to explicitly set the correct density for every bitmap
they create.
This is an attempt to fix that situation, by define the default density of bitmaps
to be the main screen's density, except for old apps where it is the original default
density.
Actually implementing this is not so great, though, because the Bitmap constructors
can't really know anything about who is calling them to know which density to use.
So at this level the compatibility mode is defined per-process -- meaning the initial
package loaded into a process defines the default bitmap density, and everyone else
loaded in later on has to live with that.
In practice this shouldn't be much of a problem, there shouldn't be much mixing of
old vs. new apps in a process. It does mean that, going forward, if a developer is
going to use shared user IDs for this, they will need to make sure either that all of
their apps are in the same compatibility mode, or that their code explicitly sets the
density of bitmaps it receives. This isn't all that great, but I think it is worth
the benefit of allowing people who write modern apps to not have to deal with bitmap
densities.
This change also does some cleanup of the density management (making sure to always
copy over bitmap densities, etc) and adds java docs to explain the various ways
density is set and used by the system.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
The Bitmap functions to get the scaled width/height couldn't actually
do the right thing because they didn't know the destination they would
be drawing to. Now there are two forms of them, taking an explicit
parameter specifying the destination.
The function is used to rebuild any caches associated with the bitmap.
In the case of purgeable bitmaps, this call ensures that the pixels
are decoded for drawing, and therefore prefetching techniques
implemented by callers can be leveraged.
