[scribus] Scribus and long documents.

[Cezary Grabski]

Dnia sobota, 13 czerwca 2015 09:28:02 JLuc pisze:
> the tool to understand where the slowishness comes from
> seems to be  valgrind
> 
> i used it once and found out the culprit was scPainter::endLayer method,
> costly and called too many times.
> it'd be interesting to test and see if its the same in your situation.
> 
> JLuc
> 
> Le 13/06/2015 01:34, William Bader a écrit :
> >> Date: Fri, 12 Jun 2015 08:22:15 -0400
> >> From: John at wexfordpress.com
> >> To: scribus at lists.scribus.net
> >> Subject: [scribus] Scribus and long documents.
> >> 
> >> Scribus has a serious flaw, one that
> >> limits its practical utility to short documents.
> >> This is not a flaw susceptible of a quick fix, or
> >> even a slow fix.
> >> 
> >> A book length  document of 100 pages or more
> >> slows the program down to a point that is not
> >> tolerable. If one breaks down the document into
> >> ten page segments then problems occur in page
> >> numbering, the TOC, indexing and so on.
> > 
> > Could you post a sample document?
> > It might be possible to build a version of Scribus with gcc -pg profiling
> > to have an idea of what is happening. If you double the number of pages,
> > is the slowness predictable? Does it get twice as slow or four times as
> > slow? Are the 100 pages all linked text frames so that any change to the
> > first page requires recalculating everything through to the last page? Is
> > the book divisible into short chapters so that the text frame on the last
> > page of one chapter does not have to be linked to the text frame on the
> > first page of the next chapter? I'm not a Scribus developer, but the
> > solution might be changing the display to recalculate only currently
> > visible pages.  Many laptops and PCs now come with 16GB of RAM, so memory
> > should not be a problem.  It might be possible to store the starting
> > layout state of each page as the page is processed, and then when you
> > modify a page, the recalculation could run from the page that you changed
> > forward to the last visible page on the screen and mark the remaining
> > pages as currently uncalculated (or queue them for recalculation on a low
> > priority thread). Regards,William
> > 
> > 
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> > <http://lists.scribus.net/pipermail/scribus/attachments/20150612/884bc4a7
> > /attachment.html> ___
> > Scribus Mailing List: scribus at lists.scribus.net
> > Edit your options or unsubscribe:
> > http://lists.scribus.net/mailman/listinfo/scribus
> > See also:
> > http://wiki.scribus.net
> > http://forums.scribus.net
> 
> ___
> Scribus Mailing List: scribus at lists.scribus.net
> Edit your options or unsubscribe:
> http://lists.scribus.net/mailman/listinfo/scribus
> See also:
> http://wiki.scribus.net
> http://forums.scribus.net