72 lines
3.2 KiB
Plaintext
72 lines
3.2 KiB
Plaintext
TurboJPEG/OSS JNI 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.
|
|
|
|
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.
|
|
|
|
javac TJExample.java
|
|
|
|
builds .class files for both the front end and example code.
|
|
|
|
|
|
Performance Pitfalls
|
|
--------------------
|
|
|
|
The TurboJPEG Java front end defines several convenience methods which 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
|
|
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
|
|
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.
|
|
|
|
|
|
Note for OS X users
|
|
-------------------
|
|
|
|
/usr/lib, the directory under which libturbojpeg.dylib is installed on Mac
|
|
systems, is not part of the normal Java library path. Thus, when running a
|
|
Java application that uses TurboJPEG/OSS on Mac systems, you will need to pass
|
|
an argument of -Djava.library.path=/usr/lib to java.
|
|
|
|
|
|
Note for Solaris users
|
|
----------------------
|
|
|
|
/opt/libjpeg-turbo/lib, the directory under which libturbojpeg.so is installed
|
|
on Solaris systems, is not part of the normal Java library path. Thus, when
|
|
running a Java application that uses TurboJPEG/OSS on Solaris systems, you will
|
|
need to pass an argument of -Djava.library.path=/opt/libjpeg-turbo/lib to java.
|
|
If using a 64-bit data model, then instead pass an argument of
|
|
-Djava.library.path=/opt/libjpeg-turbo/lib/amd64 to use the 64-bit version of
|
|
libturbojpeg.so.
|
|
|
|
|
|
Note for MinGW users
|
|
--------------------
|
|
|
|
When libjpeg-turbo is built with MinGW, the TurboJPEG/OSS dynamic library is
|
|
named libturbojpeg.dll instead of turbojpeg.dll. This is in keeping with the
|
|
convention of MinGW, and it also avoids a filename conflict when the GCC and
|
|
Visual C++ versions of the libjpeg-turbo SDK are installed on the same system.
|
|
However, the TurboJPEG/OSS JNI wrapper will not work on Windows unless the DLL
|
|
is named turbojpeg.dll. You can work around this by renaming the DLL or by
|
|
simply changing the LoadLibrary() calls in TurboJPEG.java so that they load
|
|
"libturbojpeg" instead of "turbojpeg".
|