src/lib/vampimg/JpegLib/imjmemnobs.pas

   1 unit imjmemnobs;
   2 { Delphi3 -- > jmemnobs from jmemwin }
   3 { This file provides an Win32-compatible implementation of the system-
   4   dependent portion of the JPEG memory manager. }
   5
   6 { Check jmemnobs.c }
   7 { Copyright (C) 1996, Jacques Nomssi Nzali }
   8
   9
  10 interface
  11
  12 {$I imjconfig.inc}
  13
  14 uses
  15   imjmorecfg,
  16   imjdeferr,
  17   imjerror,
  18   imjpeglib;
  19
  20 { The macro MAX_ALLOC_CHUNK designates the maximum number of bytes that may
  21   be requested in a single call to jpeg_get_large (and jpeg_get_small for that
  22   matter, but that case should never come into play).  This macro is needed
  23   to model the 64Kb-segment-size limit of far addressing on 80x86 machines.
  24   On those machines, we expect that jconfig.h will provide a proper value.
  25   On machines with 32-bit flat address spaces, any large constant may be used.
  26
  27   NB: jmemmgr.c expects that MAX_ALLOC_CHUNK will be representable as type
  28   size_t and will be a multiple of sizeof(align_type). }
  29
  30 const
  31   MAX_ALLOC_CHUNK = long(1000000000);
  32
  33 {GLOBAL}
  34 procedure jpeg_open_backing_store (cinfo : j_common_ptr;
  35                                    info : backing_store_ptr;
  36                                    total_bytes_needed : long);
  37
  38 { These routines take care of any system-dependent initialization and
  39   cleanup required. }
  40
  41 {GLOBAL}
  42 function jpeg_mem_init (cinfo : j_common_ptr) : long;
  43
  44 {GLOBAL}
  45 procedure jpeg_mem_term (cinfo : j_common_ptr);
  46
  47 { These two functions are used to allocate and release small chunks of
  48   memory.  (Typically the total amount requested through jpeg_get_small is
  49   no more than 20K or so; this will be requested in chunks of a few K each.)
  50   Behavior should be the same as for the standard library functions malloc
  51   and free; in particular, jpeg_get_small must return NIL on failure.
  52   On most systems, these ARE malloc and free.  jpeg_free_small is passed the
  53   size of the object being freed, just in case it's needed.
  54   On an 80x86 machine using small-data memory model, these manage near heap. }
  55
  56
  57 { Near-memory allocation and freeing are controlled by the regular library
  58   routines malloc() and free(). }
  59
  60 {GLOBAL}
  61 function jpeg_get_small (cinfo : j_common_ptr;
  62                          sizeofobject : size_t) : pointer;
  63
  64 {GLOBAL}
  65 {object is a reserved word in Borland Pascal }
  66 procedure jpeg_free_small (cinfo : j_common_ptr;
  67                            an_object : pointer;
  68                            sizeofobject : size_t);
  69
  70 { These two functions are used to allocate and release large chunks of
  71   memory (up to the total free space designated by jpeg_mem_available).
  72   The interface is the same as above, except that on an 80x86 machine,
  73   far pointers are used.  On most other machines these are identical to
  74   the jpeg_get/free_small routines; but we keep them separate anyway,
  75   in case a different allocation strategy is desirable for large chunks. }
  76
  77
  78 { "Large" objects are allocated in far memory, if possible }
  79
  80
  81 {GLOBAL}
  82 function jpeg_get_large (cinfo : j_common_ptr;
  83                          sizeofobject : size_t) : voidp; {far}
  84
  85 {GLOBAL}
  86 procedure jpeg_free_large (cinfo : j_common_ptr;
  87                           {var?} an_object : voidp; {FAR}
  88                           sizeofobject : size_t);
  89
  90 { This routine computes the total memory space available for allocation.
  91   It's impossible to do this in a portable way; our current solution is
  92   to make the user tell us (with a default value set at compile time).
  93   If you can actually get the available space, it's a good idea to subtract
  94   a slop factor of 5% or so. }
  95
  96 {GLOBAL}
  97 function jpeg_mem_available (cinfo : j_common_ptr;
  98                              min_bytes_needed : long;
  99                              max_bytes_needed : long;
 100                              already_allocated : long) : long;
 101
 102
 103 implementation
 104
 105 { This structure holds whatever state is needed to access a single
 106   backing-store object.  The read/write/close method pointers are called
 107   by jmemmgr.c to manipulate the backing-store object; all other fields
 108   are private to the system-dependent backing store routines. }
 109
 110
 111
 112 { These two functions are used to allocate and release small chunks of
 113   memory.  (Typically the total amount requested through jpeg_get_small is
 114   no more than 20K or so; this will be requested in chunks of a few K each.)
 115   Behavior should be the same as for the standard library functions malloc
 116   and free; in particular, jpeg_get_small must return NIL on failure.
 117   On most systems, these ARE malloc and free.  jpeg_free_small is passed the
 118   size of the object being freed, just in case it's needed.
 119   On an 80x86 machine using small-data memory model, these manage near heap. }
 120
 121
 122 { Near-memory allocation and freeing are controlled by the regular library
 123   routines malloc() and free(). }
 124
 125 {GLOBAL}
 126 function jpeg_get_small (cinfo : j_common_ptr;
 127                          sizeofobject : size_t) : pointer;
 128 var
 129   p : pointer;
 130 begin
 131   GetMem(p, sizeofobject);
 132   jpeg_get_small := p;
 133 end;
 134
 135 {GLOBAL}
 136 {object is a reserved word in Object Pascal }
 137 procedure jpeg_free_small (cinfo : j_common_ptr;
 138                            an_object : pointer;
 139                            sizeofobject : size_t);
 140 begin
 141   FreeMem(an_object, sizeofobject);
 142 end;
 143
 144 { These two functions are used to allocate and release large chunks of
 145   memory (up to the total free space designated by jpeg_mem_available).
 146   The interface is the same as above, except that on an 80x86 machine,
 147   far pointers are used.  On most other machines these are identical to
 148   the jpeg_get/free_small routines; but we keep them separate anyway,
 149   in case a different allocation strategy is desirable for large chunks. }
 150
 151
 152
 153 {GLOBAL}
 154 function jpeg_get_large (cinfo : j_common_ptr;
 155                          sizeofobject : size_t) : voidp; {far}
 156 var
 157   p : pointer;
 158 begin
 159   GetMem(p, sizeofobject);
 160   jpeg_get_large := p;
 161 end;
 162
 163 {GLOBAL}
 164 procedure jpeg_free_large (cinfo : j_common_ptr;
 165                           {var?} an_object : voidp; {FAR}
 166                           sizeofobject : size_t);
 167 begin
 168   Freemem(an_object, sizeofobject);
 169 end;
 170
 171 { This routine computes the total space still available for allocation by
 172   jpeg_get_large.  If more space than this is needed, backing store will be
 173   used.  NOTE: any memory already allocated must not be counted.
 174
 175   There is a minimum space requirement, corresponding to the minimum
 176   feasible buffer sizes; jmemmgr.c will request that much space even if
 177   jpeg_mem_available returns zero.  The maximum space needed, enough to hold
 178   all working storage in memory, is also passed in case it is useful.
 179   Finally, the total space already allocated is passed.  If no better
 180   method is available, cinfo^.mem^.max_memory_to_use - already_allocated
 181   is often a suitable calculation.
 182
 183   It is OK for jpeg_mem_available to underestimate the space available
 184   (that'll just lead to more backing-store access than is really necessary).
 185   However, an overestimate will lead to failure.  Hence it's wise to subtract
 186   a slop factor from the true available space.  5% should be enough.
 187
 188   On machines with lots of virtual memory, any large constant may be returned.
 189   Conversely, zero may be returned to always use the minimum amount of memory.}
 190
 191
 192
 193 { This routine computes the total memory space available for allocation.
 194   It's impossible to do this in a portable way; our current solution is
 195   to make the user tell us (with a default value set at compile time).
 196   If you can actually get the available space, it's a good idea to subtract
 197   a slop factor of 5% or so. }
 198
 199 const
 200   DEFAULT_MAX_MEM = long(300000);   { for total usage about 450K }
 201
 202 {GLOBAL}
 203 function jpeg_mem_available (cinfo : j_common_ptr;
 204                              min_bytes_needed : long;
 205                              max_bytes_needed : long;
 206                              already_allocated : long) : long;
 207 begin
 208   {jpeg_mem_available := cinfo^.mem^.max_memory_to_use - already_allocated;}
 209   jpeg_mem_available := max_bytes_needed;
 210 end;
 211
 212
 213 { Initial opening of a backing-store object.  This must fill in the
 214   read/write/close pointers in the object.  The read/write routines
 215   may take an error exit if the specified maximum file size is exceeded.
 216   (If jpeg_mem_available always returns a large value, this routine can
 217   just take an error exit.) }
 218
 219
 220
 221 { Initial opening of a backing-store object. }
 222
 223 {GLOBAL}
 224 procedure jpeg_open_backing_store (cinfo : j_common_ptr;
 225                                    info : backing_store_ptr;
 226                                    total_bytes_needed : long);
 227 begin
 228   ERREXIT(cinfo, JERR_NO_BACKING_STORE);
 229 end;
 230
 231 { These routines take care of any system-dependent initialization and
 232   cleanup required.  jpeg_mem_init will be called before anything is
 233   allocated (and, therefore, nothing in cinfo is of use except the error
 234   manager pointer).  It should return a suitable default value for
 235   max_memory_to_use; this may subsequently be overridden by the surrounding
 236   application.  (Note that max_memory_to_use is only important if
 237   jpeg_mem_available chooses to consult it ... no one else will.)
 238   jpeg_mem_term may assume that all requested memory has been freed and that
 239   all opened backing-store objects have been closed. }
 240
 241
 242 { These routines take care of any system-dependent initialization and
 243   cleanup required. }
 244
 245
 246 {GLOBAL}
 247 function jpeg_mem_init (cinfo : j_common_ptr) : long;
 248 begin
 249   jpeg_mem_init := DEFAULT_MAX_MEM;   { default for max_memory_to_use }
 250 end;
 251
 252 {GLOBAL}
 253 procedure jpeg_mem_term (cinfo : j_common_ptr);
 254 begin
 255
 256 end;
 257
 258
 259 end.