History log of /frameworks/base/core/jni/android/graphics/NinePatch.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a35778c799e8073a42b9e22191bde9d838327ab7 06-Nov-2014 John Reck <jreck@google.com> Yank ResourceCache out of Caches

Bug: 17947547

Pull the ResourceCache (aka, ref-counting side channel) out of
Caches so that DisplayListRenderer doesn't use Caches, avoiding
the risk of instantiating Caches on the wrong thread or
without a GL context

Change-Id: I7d63b70b3b0a0163308c5dedd6ef255eadebe8fd
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
6ba30b85ddfbe37c338ee8dde3dd33322eb38d47 15-Jul-2014 Behdad Esfahbod <behdad@google.com> Add android.Paint that inherits SkPaint

The idea is that extra paint parameters that only affect text layout
(not rendering) will go in android.Paint instead of going into
SkPaintOptionsAndroid. We will eventually move those out of SkPaint
too.

This is currently implemented in PaintImpl.cpp. Will be renamed when
current Paint.cpp that has JNI bits is moved to android_graphics_Paint.cpp.

Change-Id: Iba66c34dea5da503a13b9c864cb9f2211ac4ba7d
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
8872b38ef403cc2c44aca07d392f5e9426fd7f54 23-Jun-2014 Derek Sollenberger <djsollen@google.com> Separate Canvas JNI code from the implementation.

This introduces Canvas.h which is a pure virtual interface that
is intended to be used by both Skia and HWUI implementation. To help
stage this transition this CL only introduces the interface and Skia
implementation. The interface is not intended to be final and will
undoubtedly go through iterations in both style and location as we
look to introduce the HWUI implementation.

BUG:15672762
Change-Id: Ibaccdddb87d3b9358f4f0c1d317ead5282d4ee16
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
580ff8142b7d0455d0d41ee77572b4f55dd935f0 17-Jul-2014 John Reck <jreck@google.com> Revert "Separate Canvas JNI code from the implementation."

This reverts commit e28a5afee885cd69a5be5809f88116b601cb1a72.

Appears to cause memory corruption and random appearances of
chinese

Bug: 16343240
Bug: 16336642

Change-Id: Ife169181f40adff4b12948ed5f9d3a88dcec935b
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
f5d6c555c3430f6e423952ba3ab024380e550bba 23-Jun-2014 Derek Sollenberger <djsollen@google.com> Separate Canvas JNI code from the implementation. DO NOT MERGE

This introduces Canvas.h which is a pure virtual interface that
is intended to be used by both Skia and HWUI implementation. To help
stage this transition this CL only introduces the interface and Skia
implementation. The interface is not intended to be final and will
undoubtedly go through iterations in both style and location as we
look to introduce the HWUI implementation.

BUG:15672762
Change-Id: Idefadede356f688edb8eb09b4a02aa01b4077f62
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
5c3d927e17e98e8fd4a9f3c86f7f4def0bcfa816 08-May-2014 Florin Malita <fmalita@google.com> Add a native Canvas wrapper.

Instead of storing a direct SkCanvas reference, Canvas now tracks
an opaque native wrapper class. The native wrapper can be used to
store additional info for emulating deprecated Skia features
(at this point it only stores a canvas).

Some notes:

* all native handle -> SkCanvas conversions are routed through a
handful of native utility methods.
* safeCanvasSwap() refactored as a lower level setNativeBitmp() - which
is what clients need.
* removed unused get_thread_msec() (Canvas.cpp)

Change-Id: I715a5a6f1e1621c1cfc1e510ae4f2ea15cf11114
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
2e0103eb340822f9d580c1aa8492bae8394b8243 04-Apr-2014 Leon Scroggins III <scroggo@google.com> Remove SkFloatToScalar.

Now that SkScalar is always float (it may someday be double, but
float to double is trivial), remove callers of SkFloatToScalar,
which is deprecated in Skia.

BUG:13694396

Change-Id: I524a9bb6f7702bc810bac55fb9d2cd5361a01cf7
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
36bef0bf30d6bae48cf3837df351075ca4fce654 20-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Make graphics classes 64-bit compatible

This a merger of two commits submitted to AOSP by
the following authors:

ashok.bhat@arm.com, david.butcher@arm.coma
craig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com

Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.

Commit messages below:

================================================
AArch64: Make graphics classes 64-bit compatible

Changes in this patch include

[x] Long is used to store native pointers as they can
be 64-bit.

[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)

[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.

Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>

==================================================================

AArch64: Use long for pointers in graphics/Camera

For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.

In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)

Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>

===================================================================

Change-Id: Id5793fa0ebc17ee8b1eecf4b3f327977fdccff71
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
7023df08f14ec5dee76ac54c03e870f84e297636 27-Jan-2014 Narayan Kamath <narayan@google.com> Revert "AArch64: Make graphics classes 64-bit compatible"

This reverts commit 18b4cbeedef21c1fa666a110a157bab66edff976.

Change-Id: I0c52983a3ab1ace3ff743de546a43eca28e5cb0e
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
18b4cbeedef21c1fa666a110a157bab66edff976 20-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Make graphics classes 64-bit compatible

This a merger of two commits submitted to AOSP by
the following authors:

ashok.bhat@arm.com, david.butcher@arm.coma
craig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com

Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.

Commit messages below:

================================================
AArch64: Make graphics classes 64-bit compatible

Changes in this patch include

[x] Long is used to store native pointers as they can
be 64-bit.

[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)

[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.

Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>

==================================================================

AArch64: Use long for pointers in graphics/Camera

For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.

In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)

Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>

===================================================================

Change-Id: Ib3eab85ed97ea3e3c227617c20f8d213f17d4ba0
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
e3b0a0117a2ab4118f868a731b238fe8f2430276 27-Jun-2013 Romain Guy <romainguy@google.com> Refcount 9-patches and properly handle GC events

This change adds refcounting of Res_png_9patch instances, the native
data structure used to represent 9-patches. The Dalvik NinePatch class
now holds a native pointer instead of a Dalvik byte[]. This pointer
is used whenever we need to draw the 9-patch (software or hardware.)

Since we are now tracking garbage collection of NinePatch objects
libhwui's PatchCache must keep a list of free blocks in the VBO
used to store the meshes.

This change also removes unnecessary instances tracking from
GLES20DisplayList. Bitmaps and 9-patches are refcounted at the
native level and do not need to be tracked by the Dalvik layer.

Change-Id: Ib8682d573a538aaf1945f8ec5a9bd5da5d16f74b
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
b13b9bdad2baf6ad1ec2e56b6b7598fa20f55fc4 18-Feb-2012 Mathias Agopian <mathias@google.com> frameworks/base refactoring.

step 2: move libutils headers to their new home: androidfw

Change-Id: I14624ba23db92a81f2cb929f104386e1fab293ef
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
71f2cf116aab893e224056c38ab146bd1538dd3e 20-Oct-2011 Steve Block <steveblock@google.com> Rename (IF_)LOGV(_IF) to (IF_)ALOGV(_IF) DO NOT MERGE

See https://android-git.corp.google.com/g/#/c/143865

Bug: 5449033
Change-Id: I0122812ed6ff6f5b59fe4a43ab8bff0577adde0a
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
4cb1753ec6e90d7e747880c599dc1c164a568cf3 13-Apr-2011 Elliott Hughes <enh@google.com> Remove useless forward declarations.

Change-Id: I8f191367acb18ea9a3f807e791099e0485b1b249
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
69a017bc1d1649350f830dfada5c6ed5eac0b770 08-Apr-2011 Elliott Hughes <enh@google.com> More JNI exception-throwing cleanup.

There are a few (unimportant) bug fixes here. There were several attempts to
throw exceptions in situations where there's already a pending exception.

There were also cases where the code was wrong; it was checking for a NULL
return from Get*ArrayElements and throwing NPE, but passing NULL is an error
that causes a crash and a NULL return means an exception has already been
thrown. I didn't want to get into the Scoped* classes just yet, but that
was by far the easiest way to fix this.

Change-Id: I0b31160ee51b96e82539f6514b8412b149dba7c3
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
8cae124af2142687a6833dbaab8a43df6dd67b43 10-Sep-2009 Dianne Hackborn <hackbod@google.com> Various cleanup around resources and nine-patches.

Remove the stuff that doesn't use preloaded drawables when in
compatibility mode, since this works fine ever since we were able
to deal with drawables in a different density than the canvas.

Change the snapshot function on View to return a snapshot at
the same size that will actually be drawn on screen (when in
compatibility mode), to be able to show scaling artifacts and
all.

This change was original an attempt to fix issue #2101917: Text
field edges appears to be improperly rounded. That turns out to
probably be something deeper in the graphics system, but also
included here is the debugging code I did to try to track down the
problem to make it easy to turn on again later.

Change-Id: I34bfca629639c7ff103f3989d88874112ef778d9
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
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/core/jni/android/graphics/NinePatch.cpp
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
d24b8183b93e781080b2c16c487e60d51c12da31 11-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@130745
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
f013e1afd1e68af5e3b868c26a653bbfb39538f8 18-Dec-2008 The Android Open Source Project <initial-contribution@android.com> Code drop from //branches/cupcake/...@124589
/frameworks/base/core/jni/android/graphics/NinePatch.cpp
54b6cfa9a9e5b861a9930af873580d6dc20f773c 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/frameworks/base/core/jni/android/graphics/NinePatch.cpp