Notes on SprExtend JPEG memory management
-----------------------------------------
Baseline huffman requirements
* Require permanent image state for cinfo struct, quantisation tables, random access huffman
  pointers and similar tables of image duration.
* Would be useful to be able to support several such cached images so that dragging a window
  containing a JPEG over a desktop using a JPEG on the pinboard doesn't thrash around decompressing
  each on the fly.

Transcoded requirements
* During transcoding, a temporary coefficient buffer (~6MB, or large!), destroyed once done.
* The same cinfo/tables as described for baseline.
* Space for the transcoded copy of the original image (~1MB?).

Notes
* Want to be user draggable, drag down, fewer images can be cached at once. Sparse dynamic areas 
  aren't user draggable. Sparse areas were introduced with Ursula, so would also cause a problem
  with the copy in RO350Hook.
* If coefficient buffer can't be allocated, fail with "Not enough memory" error, but this is
  decoupled from the general ability to plot JPEGs.
* Avoid memmove()ing images around. OK to memmove() cinfo struct, it's < 32k.
* The technical problem with an RMA based solution is that resizing a block can move the block,
  so the numerous pointers in the cinfo struct would then all need labouriously fixing up.
  Dynamic areas maintain a fixed base.

Implementation
* Drop support for RMA based memory management. SprExtend is supplied in the disc image for soft
  loading on RISC OS 3.50, which has dynamic areas, JPEGs not previously supported on 3.10 and
  still aren't.
* Could group (eg.) 8x cinfo buffers in a dynamic area since they're relatively small and point
  those into separate larger dynamic area image buffer. Shrinking the dynamic area just knocks 
  images off the end which are no longer cached (their corresponding cinfo marked as invalid). 
  However, cycling though the buffers would mean memmove()s as the size of the image buffers 
  depends on the size of the source JPEG.
* Instead, keep cinfo and image buffers together. This keeps the implementation today simple (1x
  buffer) and is extensible to more buffers, a bit like 
    SCSI map (drive 0-7) 
  we'd end up with
    JPEG workspace (image 0-7)
  or however many is deemed sensible. 2? 4? 8?
  Memory map for each of N dynamic areas thus
   00000000 cinfo                              *OR*  00000000 cinfo
  ~00000400 alloc'd tables & huffman pointers       ~00000400 transcoded image
                                                    ~00100000 alloc'd tables & huffman pointers
  A new area is created for transcoding, unlikely to ever be seen by the user since it can be
  removed once processing is complete.
* This is rather clumsy from a user dragging point of view since they have no idea which image
  is which. As all that currently happens if the (single) area is resized is SprExtend immediately
  enlarges it again as soon as another JPEG plot is needed.
  Where the source of JPEG is known (JPEG_PlotFile[Scaled|Transformed]) the dynamic area could be
  given the leafname, though Task Manager's name column isn't very wide for displaying long names
  the full one would at least appear with !Help running. In memory images would still be anonymous.
  Maybe 3 workspaces are better?
    JPEG cinfo + tables (fixed size 8x cinfo + worst case 8x quantisation tables etc known)
    JPEG huffman pointers + transcoded image (only 2 pointers to fix up when compacting)
    JPEG coefficient buffers (temporary, not seen in Task Manager)
  only the 2nd one needs garbage collection, and the hit of an occasional 1MB memmove() is probably
  insignificant compared with the cost of transcode + deJPEGing. Not benchmarked.
  Careful choice of JPOOL_ id can direct the alloc to the respective dynamic area.

In IJG terminology
* The jdatasrc storage is with whoever supplied the JPEG to plot, or in the RMA for 
  the JPEG_PlotFile[Scaled|Transformed] SWIs.
* The jdatadst storage is a temporary dynamic area (AREA_TRAN), as this doesn't need to be
  seeked it could be replaced with PipeFS.
* The compress object is held on the stack during transcoding.
* The decompress object is at the start of the respective JPEG workspace (AREA_WKSP0).
* The coefficient buffers used during transcoding are in a temporary dynamic area (AREA_COEF).
* Temporary alloc_small and alloc_large allocations are always at the end of the decompress
  object, even for allocations during compression. This memory isn't returned, but since it's
  a one shot transcode there's only a couple of kB lost in the JPEG workspace and considered
  too small to be worth reclaiming (for example, by using the RMA or another dynamic area).
