Stefan Forster wrote: > My experience shows that scribus shouldn't be used for many large pictures. > Opening a file can take hours, often ended by a crash. > > It's a known issue that's been around for a while, but it really should absurdly huge images to trigger. Memory problems are more common during PDF export, but some improvements have been made there too. At one point you used to need at least four times the uncompressed size of the image to export it to PDF, but I think that's been reduced significantly.
There was some discussion of progressively loading, processing and converting/resampling/etc images rather than loading the whole lot into RAM at once. I don't know how much if any of that sort of thing has made it into the code, but but it's probably the best way to handle image memory issues eventually, both for export and for creating display previews. A bug in Scribus (in image processing or elsewhere) could also cause it to allocate and use a huge amount of RAM that'd lead to a crash, so the issue isn't necessarily caused by normal image handling. > Observing the memory consumption gives hints to the underlying problem: > - during load all computer memory and also the swap partition is filled > Out of interest, how much RAM do you have? > 3) separate the image loading into an asynchronous, lower priority thread. > When this thread has loaded all images of the current page it should load > near images during say 60 seconds - then finish. > This sort of thing would be needed to help Scribus support longer documents better, and it's a good idea in the long run. -- Craig Ringer
