Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
104
it thereafter. So if you allocate dynamic storage for the progress struct,
make sure it will live as long as the JPEG object does. Allocating from the
JPEG memory manager with lifetime JPOOL_PERMANENT will work nicely.) You
can use the same callback routine for both compression and decompression.
The jpeg_progress_mgr struct contains four fields which are set by the library:
long pass_counter;/* work units completed in this pass */
long pass_limit;/* total number of work units in this pass */
int completed_passes;/* passes completed so far */
int total_passes;/* total number of passes expected */
During any one pass, pass_counter increases from 0 up to (not including)
pass_limit; the step size is usually but not necessarily 1. The pass_limit
value may change from one pass to another. The expected total number of
passes is in total_passes, and the number of passes already completed is in
completed_passes. Thus the fraction of work completed may be estimated as
completed_passes + (pass_counter/pass_limit)
--------------------------------------------
total_passes
ignoring the fact that the passes may not be equal amounts of work.
When decompressing, pass_limit can even change within a pass, because it
depends on the number of scans in the JPEG file, which isn't always known in
advance. The computed fraction-of-work-done may jump suddenly (if the library
discovers it has overestimated the number of scans) or even decrease (in the
opposite case). It is not wise to put great faith in the work estimate.
When using the decompressor's buffered-image mode, the progress monitor work
estimate is likely to be completely unhelpful, because the library has no way
to know how many output passes will be demanded of it. Currently, the library
sets total_passes based on the assumption that there will be one more output
pass if the input file end hasn't yet been read (jpeg_input_complete() isn't
TRUE), but no more output passes if the file end has been reached when the
output pass is started. This means that total_passes will rise as additional
output passes are requested. If you have a way of determining the input file
size, estimating progress based on the fraction of the file that's been read
will probably be more useful than using the library's value.
Memory management
-----------------
This section covers some key facts about the JPEG library's built-in memory
manager. For more info, please read structure.txt's section about the memory
manager, and consult the source code if necessary.
All memory and temporary file allocation within the library is done via the
memory manager. If necessary, you can replace the "back end" of the memory
manager to control allocation yourself (for example, if you don't want the