View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0014946 | Scribus | OS-Linux | public | 2017-08-11 10:16 | 2018-05-26 10:14 |
Reporter | rzaprianov | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.5.3 | ||||
Summary | 0014946: Suddenly start working extremely slow | ||||
Description | Hi there, I did template for a novel. Everythinig was fine and suddenly it start working very, but really slow. Slide 2-3 pages up or down takes couple of minutes, saving takes 3-4 minutes. Right click - the context menu appears after few minutes. What can be wrong? My OS is Ubuntu Linux 64, 8 cores, 12 GB, I upload the file. Regards, Rumen | ||||
Tags | No tags attached. | ||||
Patch | No | ||||
related to | 0001036 | confirmed | Severe performance problem on documents with very large number of linked frames |
|
|
|
yes, the documents takes minutes to open on my computer, too. and scrolling the pages is a chore. but the content looks like a 200 pages [warning: the rest of this comment is wrong. you can safely jump to the next note] pdf imported as vectors. which is something i would not suggest anybody to do! scribus is not a pdf editor. (even if can load and export pdfs) if you want to load a long text from a pdf, i think the best thing you can do, is to open it with libreoffice, save the text (formatted) as .odt and, then, load the libre office document into scribus text frames. you will lose some of the formatting (like tables), but you will get much over. if the original work is in indesign, you might want the document as IDML. |
|
sorry, no, it's not a vectorized text. since everything is soo slow, it's hard to make diagnostics. so i have to ask questions, now: i see a flow of text frames: how long is it? if it's longer than a few pages, you might want to cut it after max 10-20 pages... just guessing... |
|
So if understand you well the text should be imported from TXT editor, not from any other format like odt, doc etc? Yes it is a small book like 100 pages. |
|
I could make some tests to identify the problem. At first I had the same behaviour: takes minutes of loading and afterwards Scribus is unusable slow. My findings: 1. The whole document has ca 200 pages but all the text is located on page 1 just linked textfields (saw it in .sla file) 2. After deleting all the text Scribus is really fluid. 3. Refilling the text with "lorem ipsum" text occur the same slow behaviour 4. disconnect some textfieds into smaller chunks (just 4-5 Pages) and refilling the whole document again with text works fluid 5. reproducable with a new file (200 pages, linked text fields and insert text) What I guess: For a good performance Scribus renders just the pages in visible viewport, but if there are connected textfields on other pages outside the viewport Scribus render these as well. This will slow down Scribus, because it tries to render all the pages at same time. (I did not checked the code how Scribus render pages - but seems like related to connected textfields) |
|
yes, tim_occ you're probably right! nice hack, to remove the text from a text editor! (probably a bit "dangerous" but does the job for a first analysis). @rzaprianov, i think that it's a good idea to follow tim_occ's hints but: - open your file - go to the first frame, where your text chain starts - right click on the frame (and wait for a while) - content > clear now you have your file back, but without any content! in a further note i'll try to explain how you can recreate your text in a "smart" way... that is compatible with the limits of scribus. and no, sadly @rzaprianov, you got my hint wrong. please ignore what comes after "[warning:" in my first comment. you're very welcome to get formatted text from an odt file. |
|
OK I will try. In Ver.1.4 there is no problem - I did it same way as I try in Ver.1.5.3 and it works perfect, never mind it is 200 pages. I did everything same way .... and there is no problem at all. See the attached file. ver.1.4 |
|
indeed! 1.4 manages it here, too. i've not seen such a 1:1 comparison of the same long document and this ticket my be important for tracking what has to be optimized before 1.6 can get out... still, it's not a bad idea to cut the text in small chunks. really. |
|
Well, I think it should be able to process the whole document. It is not so big. Indeed it is big but ... it is not A4, but A5 quote smaller. It has big font. It is actually 110 pages, the rest are empty. If you make it with Arial 10 will be maybe no more than 20-25 pages A4. I work on Linux so I can't make that :) no Arial, no Word here ... But I think it is no so big. And let us see that the size is only 508kb's ..... |
|
Perhaps related: 0014467 ? I don't know. |
|
No, I don't think so the difference is in the file size. His file is 20 MB, my file is 508Kb. |
|
I think that if the file size is a problem or the number of the pages I should have the same problem in v.1.4 like in v.1.5, but there is no problem in 1.4. |
|
@rzaprianov, it's very likely that the main issue is the number of characters in the linked text. the analysis tim_occ did, looks correct to me. it's very likely that scribus does render the whole linked text each time something changes around one of the elements in the chain. changing this behavior is not trivial, but there might be room for improvements and avoid or optimize some expensive operations that are executed very often when scribus recalculates the characters position. for now, the "solution" is to split the text chain and not have 200 pages of linked text (but max 20 pages). or use 1.4, since it seems to better handle such cases. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-08-11 10:16 | rzaprianov | New Issue | |
2017-08-11 10:16 | rzaprianov | File Added: A5 - mirmi conf_2017.sla | |
2017-08-13 09:15 | ale | Note Added: 0044312 | |
2017-08-13 09:20 | ale | Note Added: 0044313 | |
2017-08-13 09:21 | ale | Note Edited: 0044312 | |
2017-08-13 15:27 | rzaprianov | Note Added: 0044315 | |
2017-08-13 16:07 |
|
Note Added: 0044316 | |
2017-08-13 16:41 | ale | Note Added: 0044317 | |
2017-08-13 16:46 | rzaprianov | File Added: A5 - mirmi conf_2017_V.1.4.sla | |
2017-08-13 16:46 | rzaprianov | Note Added: 0044318 | |
2017-08-13 17:14 | ale | Note Added: 0044319 | |
2017-08-13 19:19 | rzaprianov | Note Added: 0044320 | |
2017-08-13 20:52 | PeterBenedek | Note Added: 0044321 | |
2017-08-13 20:52 | PeterBenedek | Note Edited: 0044321 | |
2017-08-13 21:36 | rzaprianov | Note Added: 0044322 | |
2017-08-13 21:37 | rzaprianov | Note Added: 0044323 | |
2017-08-14 05:49 | ale | Note Added: 0044324 | |
2018-05-26 10:14 | PeterBenedek | Relationship added | related to 0001036 |