Cedric Sagne wrote: > Andreas, > > with 512 MB of RAM, loading 105 MB for an image should be fine...
Absolutely. > I admit that Photoshop on Windows has difficulties doing more than that. > In fact the whole thing about DTP (or so i thought) is using large files > and managing them efficiently, abstracting them along the way. It shouldn't have any issues. In fact, Photoshop should be able to work with images larger than physical RAM because of its use of a tile cache, scratch disk, etc. Photoshop essentially has its own virtual memory system optimised for image handling. I've certainly had no problems on the XP boxes or the OS X machine here, even when working with very large images. It's not fast of course - because it's having to use very slow disk storage to compensate for insufficient main memory - but it works. > I thought Scribus was "linking" to the files and using for memory > purposes shrunk versions of them in order to optimise memory, which is > why the workflow implies storing the images in a separate folder and > assembling the finished product... It does. However, to produce those shrunken images when the doc is loaded, and at certain other points along the way (such as when resampling the final image for inclusion in PDF output) Scribus must load and process the whole image. That's not to say there's no room for improvement. Far from it. Images can be loaded more quickly and efficiently (witness Xara), resampled more efficiently, and so on. It's also possible to be smarter about when and how they're loaded. One of the things that'd be nice would be to cache thumbnails of the images in the .sla or in a cache directory, at least optionally, and key them to the source image's mtime and size. That way we could avoid loading the source image if it hadn't changed since we generated the preview version. That would help a LOT with doc loading performance when large images are in use. QuarkXPress has been doing this for a long time, along with providing the ability to print using those preview quality images for a rough layout preview without the time cost of loading all those big images. -- Craig Ringer
