[scribus] Scribus and long documents.
JLuc
jluc at no-log.org
Sat Jun 13 07:28:02 UTC 2015
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
>
More information about the scribus
mailing list