Unit jmemnobs

Classes

Functions

jpeg_free_large - far} {GLOBAL

GLOBAL
jpeg_free_small - GLOBAL} {object is a reserved word in Borland Pascal

GLOBAL} {object is a reserved word in Object Pascal
jpeg_get_large - These two functions are used to allocate and release large chunks of memory (up to the total free space designated by jpeg_mem_available).
jpeg_get_small - These two functions are used to allocate and release small chunks of memory.
jpeg_mem_available - This routine computes the total memory space available for allocation.
jpeg_mem_init - These routines take care of any system-dependent initialization and cleanup required.
jpeg_mem_term - GLOBAL

GLOBAL
jpeg_open_backing_store - GLOBAL

Initial opening of a backing-store object.

Types

voidp

Constants

MAX_ALLOC_CHUNK

Variables


Functions


procedure jpeg_free_large (cinfo : j_common_ptr; {var?} an_object : voidp; {FAR} sizeofobject : size_t);

far} {GLOBAL

GLOBAL


procedure jpeg_free_small (cinfo : j_common_ptr; an_object : pointer; sizeofobject : size_t);

GLOBAL} {object is a reserved word in Borland Pascal

GLOBAL} {object is a reserved word in Object Pascal


function jpeg_get_large (cinfo : j_common_ptr; sizeofobject : size_t) : voidp;

These two functions are used to allocate and release large chunks of memory (up to the total free space designated by jpeg_mem_available). The interface is the same as above, except that on an 80x86 machine, far pointers are used. On most other machines these are identical to the jpeg_get/free_small routines; but we keep them separate anyway, in case a different allocation strategy is desirable for large chunks. } { "Large" objects are allocated in far memory, if possible } {GLOBAL

These two functions are used to allocate and release large chunks of memory (up to the total free space designated by jpeg_mem_available). The interface is the same as above, except that on an 80x86 machine, far pointers are used. On most other machines these are identical to the jpeg_get/free_small routines; but we keep them separate anyway, in case a different allocation strategy is desirable for large chunks. } {GLOBAL


function jpeg_get_small (cinfo : j_common_ptr; sizeofobject : size_t) : pointer;

These two functions are used to allocate and release small chunks of memory. (Typically the total amount requested through jpeg_get_small is no more than 20K or so; this will be requested in chunks of a few K each.) Behavior should be the same as for the standard library functions malloc and free; in particular, jpeg_get_small must return NIL on failure. On most systems, these ARE malloc and free. jpeg_free_small is passed the size of the object being freed, just in case it's needed. On an 80x86 machine using small-data memory model, these manage near heap. } { Near-memory allocation and freeing are controlled by the regular library routines malloc() and free(). } {GLOBAL

This structure holds whatever state is needed to access a single backing-store object. The read/write/close method pointers are called by jmemmgr.c to manipulate the backing-store object; all other fields are private to the system-dependent backing store routines. } { These two functions are used to allocate and release small chunks of memory. (Typically the total amount requested through jpeg_get_small is no more than 20K or so; this will be requested in chunks of a few K each.) Behavior should be the same as for the standard library functions malloc and free; in particular, jpeg_get_small must return NIL on failure. On most systems, these ARE malloc and free. jpeg_free_small is passed the size of the object being freed, just in case it's needed. On an 80x86 machine using small-data memory model, these manage near heap. } { Near-memory allocation and freeing are controlled by the regular library routines malloc() and free(). } {GLOBAL


function jpeg_mem_available (cinfo : j_common_ptr; min_bytes_needed : long; max_bytes_needed : long; already_allocated : long) : long;

This routine computes the total memory space available for allocation. It's impossible to do this in a portable way; our current solution is to make the user tell us (with a default value set at compile time). If you can actually get the available space, it's a good idea to subtract a slop factor of 5% or so. } {GLOBAL

for total usage about 450K } {GLOBAL


function jpeg_mem_init (cinfo : j_common_ptr) : long;

These routines take care of any system-dependent initialization and cleanup required. } {GLOBAL

These routines take care of any system-dependent initialization and cleanup required. jpeg_mem_init will be called before anything is allocated (and, therefore, nothing in cinfo is of use except the error manager pointer). It should return a suitable default value for max_memory_to_use; this may subsequently be overridden by the surrounding application. (Note that max_memory_to_use is only important if jpeg_mem_available chooses to consult it ... no one else will.) jpeg_mem_term may assume that all requested memory has been freed and that all opened backing-store objects have been closed. } { These routines take care of any system-dependent initialization and cleanup required. } {GLOBAL


procedure jpeg_mem_term (cinfo : j_common_ptr);

GLOBAL

GLOBAL


procedure jpeg_open_backing_store (cinfo : j_common_ptr; info : backing_store_ptr; total_bytes_needed : long);

GLOBAL

Initial opening of a backing-store object. This must fill in the read/write/close pointers in the object. The read/write routines may take an error exit if the specified maximum file size is exceeded. (If jpeg_mem_available always returns a large value, this routine can just take an error exit.) } { Initial opening of a backing-store object. } {GLOBAL


Types


voidp = pointer
This file provides an Win32-compatible implementation of the system- dependent portion of the JPEG memory manager. } { Check jmemnobs.c } { Copyright (C) 1996, Jacques Nomssi Nzali

Constants

MAX_ALLOC_CHUNK = long(1000000000)

The macro MAX_ALLOC_CHUNK designates the maximum number of bytes that may be requested in a single call to jpeg_get_large (and jpeg_get_small for that matter, but that case should never come into play). This macro is needed to model the 64Kb-segment-size limit of far addressing on 80x86 machines. On those machines, we expect that jconfig.h will provide a proper value. On machines with 32-bit flat address spaces, any large constant may be used. NB: jmemmgr.c expects that MAX_ALLOC_CHUNK will be representable as type size_t and will be a multiple of sizeof(align_type).

Variables