Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

pointers, and insert a pointer to the struct into the "src" field of the JPEG

decompression object. This can be done in-line in your setup code if you

like, but it's probably cleaner to provide a separate routine similar to the

jpeg_stdio_src() or jpeg_mem_src() routines of the supplied source managers.

For more information, consult the memory and stdio source and destination

managers in jdatasrc.c and jdatadst.c.

I/O suspension

--------------

Some applications need to use the JPEG library as an incremental memory-to-

memory filter: when the compressed data buffer is filled or emptied, they want

control to return to the outer loop, rather than expecting that the buffer can

be emptied or reloaded within the data source/destination manager subroutine.

The library supports this need by providing an "I/O suspension" mode, which we

describe in this section.

The I/O suspension mode is not a panacea: nothing is guaranteed about the

maximum amount of time spent in any one call to the library, so it will not

eliminate response-time problems in single-threaded applications. If you

need guaranteed response time, we suggest you "bite the bullet" and implement

a real multi-tasking capability.

To use I/O suspension, cooperation is needed between the calling application

and the data source or destination manager; you will always need a custom

source/destination manager. (Please read the previous section if you haven't

already.) The basic idea is that the empty_output_buffer() or

fill_input_buffer() routine is a no-op, merely returning FALSE to indicate

that it has done nothing. Upon seeing this, the JPEG library suspends

operation and returns to its caller. The surrounding application is

responsible for emptying or refilling the work buffer before calling the

JPEG library again.

Compression suspension:

For compression suspension, use an empty_output_buffer() routine that returns

FALSE; typically it will not do anything else. This will cause the

compressor to return to the caller of jpeg_write_scanlines(), with the return

value indicating that not all the supplied scanlines have been accepted.

The application must make more room in the output buffer, adjust the output

buffer pointer/count appropriately, and then call jpeg_write_scanlines()

again, pointing to the first unconsumed scanline.

When forced to suspend, the compressor will backtrack to a convenient stopping

point (usually the start of the current MCU); it will regenerate some output

data when restarted. Therefore, although empty_output_buffer() is only