Eliminated the awkward and confusing "TurboJPEG/OSS" designation, since there are no other active implementations of the TurboJPEG API anymore; don't refer to the libjpeg API library as "libjpeg-turbo" anymore, since that can be confusing; ARM v7s build instructions
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@919 632fc199-4ca6-4c93-a231-07263d6284db
This commit is contained in:
32
java/README
32
java/README
@@ -1,25 +1,25 @@
|
||||
TurboJPEG/OSS Java Wrapper
|
||||
==========================
|
||||
TurboJPEG Java Wrapper
|
||||
======================
|
||||
|
||||
TurboJPEG/OSS can optionally be built with a Java Native Interface wrapper,
|
||||
which allows the TurboJPEG/OSS dynamic library to be loaded and used directly
|
||||
from Java applications. The Java front end for this is defined in several
|
||||
classes located under org/libjpegturbo/turbojpeg. The source code for these
|
||||
Java classes is licensed under a BSD-style license, so the files can be
|
||||
incorporated directly into both open source and proprietary projects without
|
||||
restriction. A Java archive (JAR) file containing these classes is also
|
||||
shipped with the "official" distribution packages of libjpeg-turbo.
|
||||
The TurboJPEG shared library can optionally be built with a Java Native
|
||||
Interface wrapper, which allows the library to be loaded and used directly from
|
||||
Java applications. The Java front end for this is defined in several classes
|
||||
located under org/libjpegturbo/turbojpeg. The source code for these Java
|
||||
classes is licensed under a BSD-style license, so the files can be incorporated
|
||||
directly into both open source and proprietary projects without restriction. A
|
||||
Java archive (JAR) file containing these classes is also shipped with the
|
||||
"official" distribution packages of libjpeg-turbo.
|
||||
|
||||
TJExample.java, which should also be located in the same directory as this
|
||||
README file, demonstrates how to use the TurboJPEG/OSS Java front end to
|
||||
compress and decompress JPEG images in memory.
|
||||
README file, demonstrates how to use the TurboJPEG Java API to compress and
|
||||
decompress JPEG images in memory.
|
||||
|
||||
|
||||
Performance Pitfalls
|
||||
--------------------
|
||||
|
||||
The TurboJPEG Java front end defines several convenience methods that can
|
||||
allocate image buffers or instantiate classes to hold the result of compress,
|
||||
The TurboJPEG Java API defines several convenience methods that can allocate
|
||||
image buffers or instantiate classes to hold the result of compress,
|
||||
decompress, or transform operations. However, if you use these methods, then
|
||||
be mindful of the amount of new data you are creating on the heap. It may be
|
||||
necessary to manually invoke the garbage collector to prevent heap exhaustion
|
||||
@@ -27,8 +27,8 @@ or to prevent performance degradation. Background garbage collection can kill
|
||||
performance, particularly in a multi-threaded environment (Java pauses all
|
||||
threads when the GC runs.)
|
||||
|
||||
The Java front end always gives you the option of pre-allocating your own
|
||||
source and destination buffers, which allows you to re-use these buffers for
|
||||
The TurboJPEG Java API always gives you the option of pre-allocating your own
|
||||
source and destination buffers, which allows you to re-use those buffers for
|
||||
compressing/decompressing multiple images. If the image sequence you are
|
||||
compressing or decompressing consists of images of the same size, then
|
||||
pre-allocating the buffers is recommended.
|
||||
|
||||
Reference in New Issue
Block a user