J.U. Anderegg ([EMAIL PROTECTED]) wrote To [EMAIL PROTECTED] on Tue, 
May 21, 2002 at 05:31:53PM +0200:

> Inserting JPEG into a PDF file is a simple file copy - given the URI,
> bits/pixel and color model. The latter are coded within JPEG files. PDF
> stores the image once and allows multiple references to it. Is programmed
> caching superior to the caching of the file system?
> >From PDF view, memory = (JPEG file size + PDF encoded image) is needed at
> most during the lifetime of an output page in memory. Why isn't that so:
> device independence, AWT compatibility?
> Similar considerations apply to GIF, TIFF and Fax formats.

I'm not sure exactly what you're referring to.

My hacks primarily address the issue I had of rendering large vector
plots of maps to pdf. The images that are used do not already exist as
jpegs or any other form; they are an amalgam of vector routines and
raster icons, and the icons are rotated in memory for
speed. Generating this mess to svg, then into pdf was very time
consuming and memory-intensive. So I switched to "rendering" directly
into the pdf using the existing PDFGraphics2D, which allowed me to use
the exact same routines that I use to render to the AWT window. 

Once I got that working I ran into memory problems, because the
current design of the PDF generation code keeps a lot of things in
memory as buffers, I believe because it doesn't know exactly where in
the pdf file the data will be placed at final output - it's juggling
layout etc.

So, this is not a case of file buffering, but of storing chunks
of rendered pdf for later use. My hack puts them in tempfiles rather
than in in-memory buffers. This is obviously slower but more scalable.

As for programmed caching being superior to file system caching, well,
that's another debate and really depends on the operating system. For
windows systems, especially over SMB networks, the answer is generally
yes, because they are very unaggressive about disk caching and they flush
a lot. Linux on the other hand is very aggressive (on my 754MB
development machine, 320MB is being used for disk cache), and flushes
less often. At least in my experience... in one case I got a 20x speed
increase with a decent cacheing framework; I finally noticed that machines
with crappy disk drive subsystems were far slower than those with good
ones even at the same memory and cpu speed.


Paul Reavis                                      [EMAIL PROTECTED]
Design Lead
Partner Software, Inc.                        http://www.partnersoft.com

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to