| 9f3436c3b153b55257caca0345c8135514b26945 |
|
11-Jun-2015 |
Sam Hasinoff <hasinoff@google.com> |
Fix build break for unbundled apps
Change-Id: I72f09e303c77873dbc77417b06b71339392dd015
/external/jpeg/Android.mk
|
| 7dbc6441d8158d28b7120a3ce6ea68bc08f4c295 |
|
23-Apr-2015 |
Matt Sarett <msarett@google.com> |
libjpeg should always use jmemnobs
When using jmem-android with libjpeg, the client has the option
to provide a value for maximum memory usage (or use a default
value) during the decode. When this value for maximum memory usage
would be exceeded, jmem-android backs data arrays with temp files
to stay below the memory limit. The CL that defines this memory
limit is at:
https://skia.googlesource.com/skia/+/2295c6332512833760060d803cf6ad19a28adc51
However, it is unclear why the current limit was chosen.
Unfortunately, these temp files are not guaranteed to have unique
names, leading to bugs where multiple arrays are backed up to the
same file. The original purpose of this CL was to fix this bug.
However, attempting to fix this bug has led to a variety of
additional questions.
The creation of temp files is tricky in this type of library.
Concerns about the creation of temp files include security,
performance of writing to disk, and difficulty of finding the
right directory to use from a library that could be used by an
arbitrary process.
Additionally, there have already been complaints about jmem-android
from the users of the Java API. b/2791339 explains that writing
to disk is extremely slow, and it causes users of the decoder to
need WRITE_EXTERNAL_STORAGE permission in order to decode.
This led to the creation of jmem-ashmem.c as the memory
implementation for libjpeg to be used by apps. This acts in the
same way as jmem-android up until the arbitrary maximum memory
usage value is reached. At this point, jmem-ashmem uses ashmem
to back up the data arrays instead of temp files.
We first considered using jmem-ashmem all the time, since it was
introduced as a faster alternative to jmem-android that does not
require extra permissions and does not have known bugs.
However, thinking further about jmem-ashmem, we feel that it is
not a good alternative. It is quite odd to solve the problem
of being "out of memory" (having reached the memory limit) by
choosing to allocate more memory.
It seems more intuitive to simply allocate memory on the heap
until we run out or the process is killed.
Using jmemnobs.c follows exactly this approach. It has no memory
limit and will allocate memory until it runs out or is killed.
Another alternative would be to modify jmem-android to simply
error exit once we reach a maximum memory limit. This would
make behavior more predicatble, but may prevent us from decoding
images that could possibly be decoded. This would also bring up
the question of how we choose this maximum memory limit.
BUG:20541233
Change-Id: Iae944ac8588769c3e24f25f64de847e58cc2ad2e
/external/jpeg/Android.mk
|
| 4660f767bca6ddae968d4f5fcfa2fd5ab80c4692 |
|
04-Dec-2014 |
Elliott Hughes <enh@google.com> |
libjpeg should #define __ARM_HAVE_NEON.
Bug: 18556103
Change-Id: Ifcedc68c4625b07a1bb494085842003f35bacdd4
/external/jpeg/Android.mk
|
| 9f6aca34abc4842152e49fd553e357adc2f3f357 |
|
16-Oct-2014 |
Chih-Hung Hsieh <chh@google.com> |
Add -no-integrated-as at local level.
Later we will enable integrated-as as default at the global level.
BUG: 17820427
Change-Id: I60f815a4e22cb157c240005e973f459da93cdb91
/external/jpeg/Android.mk
|
| e08a211ab982d1877e0b4685f7c2b6560e1f4185 |
|
13-Nov-2013 |
Xun Sun <xun.sun@intel.com> |
Enable SSE optimized IDCT in jpeg decoding for x86 platform.
Change-Id: I9a646a0ca208e9ad1a11929f3fd71b7d19592dd9
Signed-off-by: Xun Sun <xun.sun@intel.com>
/external/jpeg/Android.mk
|
| 6a3be8dfbb7c258e7fbbd11f1078bf11c9be89bd |
|
11-Jun-2012 |
Prajakta Gudadhe <pgudadhe@nvidia.com> |
JPEG decoding neon optimization
Bug: 6633342
The idct and color conversion are neon accelerated.
Note, neon accelerations and armv6 assembly accelerations are muturaly
exclusive. When neon is not available, the armv6 assembly is used.
Change-Id: I4a7093e2199893154d64b43f2b0282971c19426c
/external/jpeg/Android.mk
|
| b84b1409efc0e2df28ff0969e10d33e40fc458f2 |
|
28-Feb-2013 |
Andrew Hsieh <andrewhsieh@google.com> |
am 14d8fa03: Merge "[MIPS] Inverse DCT optimizations"
* commit '14d8fa0373cc75eea1bd8413b7757b918a4ff3c7':
[MIPS] Inverse DCT optimizations
|
| 7fb4687279b703d9f866cefac5fc6967fb81068a |
|
26-Feb-2013 |
Angus Kong <shkong@google.com> |
Add static library target.
Change-Id: Ibd4dcf7aa46c4198d7baeecf19fd330e647abe6d
/external/jpeg/Android.mk
|
| b98230c8207af91559f0dd12ea07724b893a738b |
|
07-Feb-2013 |
Angus Kong <shkong@google.com> |
Make libjpeg built against NDK
Change-Id: I2570cfe1360af6eb0dcbb14bcc70f1dc6f2b5fe0
/external/jpeg/Android.mk
|
| 71ee859f6d3b654092fe1cba126d2c176a201196 |
|
06-Nov-2012 |
Raghu Gandham <raghu@mips.com> |
[MIPS] Inverse DCT optimizations
Change-Id: I1f3aa64d8d19b515876fe83b6df86c27bffa4530
/external/jpeg/Android.mk
|
| 6553d244f16f1ce8e6b5e018fd1b49e98a3c1de3 |
|
04-Jul-2012 |
tengfei.zhao <tengfei.zhao@intel.com> |
Add SSE optmized IDCT in JPEG decoding for INTEL Atom platform.
ADD SSE optmized IDCT. It makes album2D workload about 18%
faster than jidctfst.c. The major implementation is at
"jidctintelsse.c".
Change-Id: I6dc6f367158172b468e85e7eae249027eb1766cf
/external/jpeg/Android.mk
|
| 4736a38e2514bfe50b0241d2053befea82822944 |
|
10-Dec-2010 |
Chia-chi Yeh <chiachi@android.com> |
libjpeg: Use the new fast-and-accurate IDCT method for ARMv6+ devices.
As another AA&N implementation, it runs 9-10% faster than jidctfst.S
and 11-15% faster than jidctfst.c. As another IDCT method, it runs
17-20% faster than JDCT_ISLOW method and provides the same accuracy
or even better.
Change-Id: I81783c310d6dac5aaf84c03a4cf20662f466564c
/external/jpeg/Android.mk
|
| c2cf571b568278c7a347e656bfd2522378b7112d |
|
10-Dec-2010 |
Chia-chi Yeh <chiachi@android.com> |
libjpeg: Remove the old assembly code for ARM.
A much better one is coming.
Change-Id: I60d8c227d573fcbff10af363d69405e9fbd0c147
/external/jpeg/Android.mk
|
| 7b6961ad552a5f748fbf4b287e8838c7495dacb5 |
|
11-Aug-2010 |
Joseph Wen <josephwen@google.com> |
Add ashmem implementation for libjpeg decoder's backing store
Bug: 2791339
Change-Id: Ibfb48c0016ec5bdd8e8220e0479d88d5a2aaa1c1
/external/jpeg/Android.mk
|
| 3147fbe7688fc353e6ae03825a37cf101a4ee01d |
|
12-Jul-2010 |
Joseph Wen <josephwen@google.com> |
Support tile-based jpeg decoding.This change only handles the baseline case.
The functionality of tile-based decode is enabled by default.
To disable it, mark off the flag of ANDROID_TILE_BASED_DECODE in Android.mk
Change-Id: Ib9f7839095b0ca55260c28d3c499c871e81332ea
/external/jpeg/Android.mk
|
| c4e357f36260ba7d7dc279b43dd94453238943d1 |
|
06-Jan-2010 |
Wei-Ta Chen <weita@google.com> |
Build libjpeg to a shared library, so that various packages/libraries can dynamically link to it.
/external/jpeg/Android.mk
|
| 9f5d49a1588e438ae7ceabd0c94172117e3303aa |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/external/jpeg/Android.mk
|
| 38777fb873b051d8d8bffbbd1de731cc9574a33b |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/external/jpeg/Android.mk
|
| 9175dba76b0c31e0870fe074d476650cf258071c |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/external/jpeg/Android.mk
|
| d9bb1510bee7d9bf2a0f2699c647a65e67ab9cf8 |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/external/jpeg/Android.mk
|