0d221012ff5fd314711c00ed30e9b807b9c454c1 |
|
30-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix #2018814: System cannot correctly render assets with "wrap_content" attribute in QVGA It turns out we were not returning the density for anything retrieved from a TypedArray... which basically means any bitmap references from a layout or style...!!! This is now fixed. Also fiddle with the density compatibility mode to turn on smoothing in certain situations, helping the look of things when they need to scale and we couldn't do the scaling at load time.
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
96e240f25a97c10bba863df328ed73a82c34ff61 |
|
27-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Fiddle with default densities to try to sanitize the API. 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.
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
11ea33471e1a14a8594f0b2cd012d86340dd3bd8 |
|
23-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Allow for screen density drawables in compatibility mode. 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.
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
a53b828635fce8b6b2d3e3377d74d72070056623 |
|
17-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Add "nodpi" density, and expose a bunch of density-related APIs. Also update the DpiTest app to use nodpi images, and try to have a mode where it turns off compatibility though it's not quite working.
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
4566b79736f236c0f605c57130d1fa954f4642d6 |
|
18-Jun-2009 |
Phil Dubach <phillipd@google.com> |
Fix Canvas.finalize() for the case where the constructor throws an exception before the native canvas instance was created. If the canvas constructors throw an exception (because the bitmap passed in is immutable or already recycled), the constructor terminates early without allocating the native canvas instance. For the most part, that's okay, since the Canvas instance will never be returned to the application. However, the GC will still call finalize() on the half-initialized Canvas. The native methods for Canvas all assume that the canvas pointer passed down is not null.
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
caf0df1b7f99736aed1a0b923ef278fc4fd0fcca |
|
27-Apr-2009 |
Mike Reed <reed@google.com> |
Add call to (new) Canvas.freeCaches() in response to low-memory This is in conjunction with removing a similar call made by the browser. Now it will be centralized, and the browser's call site will be removed.
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/graphics/java/android/graphics/Canvas.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/graphics/java/android/graphics/Canvas.java
|