view release on metacpan or  search on metacpan

src/Source/LibJPEG/install.txt  view on Meta::CPAN

If your machine has sufficiently fast floating point hardware, you may find
that the float DCT method is faster than the integer DCT methods, even
after tweaking the integer multiply macros.  In that case you may want to
make the float DCT be the default method.  (The only objection to this is
that float DCT results may vary slightly across machines.)  To do that, add
"#define JDCT_DEFAULT JDCT_FLOAT" to jconfig.h.  Even if you don't change
the default, you should redefine JDCT_FASTEST, which is the method selected
by djpeg's -fast switch.  Don't forget to update the documentation files
(usage.txt and/or cjpeg.1, djpeg.1) to agree with what you've done.

If access to "short" arrays is slow on your machine, it may be a win to
define type JCOEF as int rather than short.  This will cost a good deal of
memory though, particularly in some multi-pass modes, so don't do it unless
you have memory to burn and short is REALLY slow.

If your compiler can compile function calls in-line, make sure the INLINE
macro in jmorecfg.h is defined as the keyword that marks a function
inline-able.  Some compilers have a switch that tells the compiler to inline
any function it thinks is profitable (e.g., -finline-functions for gcc).
Enabling such a switch is likely to make the compiled code bigger but faster.

In general, it's worth trying the maximum optimization level of your compiler,
and experimenting with any optional optimizations such as loop unrolling.
(Unfortunately, far too many compilers have optimizer bugs ... be prepared to
back off if the code fails self-test.)  If you do any experimentation along
these lines, please report the optimal settings to jpeg-info@jpegclub.org so
we can mention them in future releases.  Be sure to specify your machine and
compiler version.


HINTS FOR SPECIFIC SYSTEMS
==========================

We welcome reports on changes needed for systems not mentioned here.  Submit
'em to jpeg-info@jpegclub.org.  Also, if configure or ckconfig.c is wrong
about how to configure the JPEG software for your system, please let us know.


Acorn RISC OS:

(Thanks to Simon Middleton for these hints on compiling with Desktop C.)
After renaming the files according to Acorn conventions, take a copy of
makefile.ansi, change all occurrences of 'libjpeg.a' to 'libjpeg.o' and
change these definitions as indicated:

CFLAGS= -throwback -IC: -Wn
LDLIBS=C:o.Stubs
SYSDEPMEM=jmemansi.o
LN=Link
AR=LibFile -c -o

Also add a new line '.c.o:; $(cc) $< $(cflags) -c -o $@'.  Remove the
lines '$(RM) libjpeg.o' and '$(AR2) libjpeg.o' and the 'jconfig.h'
dependency section.

Copy jconfig.txt to jconfig.h.  Edit jconfig.h to define TWO_FILE_COMMANDLINE
and CHAR_IS_UNSIGNED.

Run the makefile using !AMU not !Make.  If you want to use the 'clean' and
'test' makefile entries then you will have to fiddle with the syntax a bit
and rename the test files.


Amiga:

SAS C 6.50 reportedly is too buggy to compile the IJG code properly.
A patch to update to 6.51 is available from SAS or AmiNet FTP sites.

The supplied config files are set up to use jmemname.c as the memory
manager, with temporary files being created on the device named by
"JPEGTMP:".


Atari ST/STE/TT:

Copy the project files makcjpeg.st, makdjpeg.st, maktjpeg.st, and makljpeg.st
to cjpeg.prj, djpeg.prj, jpegtran.prj, and libjpeg.prj respectively.  The
project files should work as-is with Pure C.  For Turbo C, change library
filenames "pc..." to "tc..." in each project file.  Note that libjpeg.prj
selects jmemansi.c as the recommended memory manager.  You'll probably want to
adjust the DEFAULT_MAX_MEM setting --- you want it to be a couple hundred K
less than your normal free memory.  Put "#define DEFAULT_MAX_MEM nnnn" into
jconfig.h to do this.

To use the 68881/68882 coprocessor for the floating point DCT, add the
compiler option "-8" to the project files and replace pcfltlib.lib with
pc881lib.lib in cjpeg.prj and djpeg.prj.  Or if you don't have a
coprocessor, you may prefer to remove the float DCT code by undefining
DCT_FLOAT_SUPPORTED in jmorecfg.h (since without a coprocessor, the float
code will be too slow to be useful).  In that case, you can delete
pcfltlib.lib from the project files.

Note that you must make libjpeg.lib before making cjpeg.ttp, djpeg.ttp,
or jpegtran.ttp.  You'll have to perform the self-test by hand.

We haven't bothered to include project files for rdjpgcom and wrjpgcom.
Those source files should just be compiled by themselves; they don't
depend on the JPEG library.  You can use the default.prj project file
of the Pure C distribution to make the programs.

There is a bug in some older versions of the Turbo C library which causes the
space used by temporary files created with "tmpfile()" not to be freed after
an abnormal program exit.  If you check your disk afterwards, you will find
cluster chains that are allocated but not used by a file.  This should not
happen in cjpeg/djpeg/jpegtran, since we enable a signal catcher to explicitly
close temp files before exiting.  But if you use the JPEG library with your
own code, be sure to supply a signal catcher, or else use a different
system-dependent memory manager.


Cray:

Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
compiler bug in old versions of Cray's Standard C (prior to 3.1).  If you
still have an old compiler, you'll need to insert a line reading
"#pragma novector" just before the loop	
    for (i = 1; i <= (int) htbl->bits[l]; i++)
      huffsize[p++] = (char) l;
in fix_huff_tbl (in V5beta1, line 204 of jchuff.c and line 176 of jdhuff.c).
[This bug may or may not still occur with the current IJG code, but it's
probably a dead issue anyway...]