[Scribus] Scribus memory requirements

[Craig Ringer]

ols6000 at sbcglobal.net wrote:
> At 11:49 PM 4/30/2007, you wrote:
>> check your /etc/fstab to see if you are using a swap file or partition and
>> then find out the size of those.
> 
> Thanks for the info.
> 
>> and we will not switch.
> 
> That's what I mean by "insistent".
> 
>> so, you dont think that 60x100mb (plus fc6's other running apps) is more than
>> your 2gb ram + some swap?
> 
> What I think is, there is no need to hold all the images in memory 
> simultaneously.

AFAIK it does not - but it uses enough RAM between the image previews
(stored uncompressed in RAM) and the image loading process that it might
well manage to run out of RAM loading an image.

> Doing so guarantees that documents will not scale up 
> (i e, there will be some documents that are too large). An image only 
> needs to be in memory when you are displaying or printing it, and 
> even for those, only at the resolution needed.

Things like colour space conversions complicate that, but even so there
are many techniques for processing images that are too large to fit in
RAM at once.

> So on a 96 dpi monitor 
> showing an image at half size, you don't need anything like 4800 dpi. 
> That would also solve another problem that I mentioned, namely, that 
> it took over 40 min for the document to crash, and then it was only 
> partly open.

That'll simply be because Scribus's memory consumption forced the OS to
start using your disk as VM swap space, which is *incredibly* slow. With
enough physical RAM - probably "only" a GB or two more than you have -
it would've opened in a fraction of the time. That said, IMO if 2GB
isn't good enough, that's a problem with the application not the computer.

Of course, I'm not volunteering to fix said problem at the moment, so
such a statement doesn't really achieve anything.

>> Do you even have a printing solution that will print those images are full
>> resolution?
> 
> Yes, but you're asking the wrong question. The right one is, how can 
> Scribus be improved to handle situations that users need, or even 
> think they need. 

There's a lot of work going on at the moment to address the big problems
in the text system, which has caused more ongoing problems and
limitations than large image handling has. There are only a few active
contributors (of whom I'm not one these days due to my work and uni
commitments) and they only have so much time, so not everything can be
done at once.

--
Craig Ringer