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]
