View Issue Details

IDProjectCategoryView StatusLast Update
0014946ScribusOS-Linuxpublic2018-05-26 10:14
Reporterrzaprianov Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.5.3 
Target VersionFixed in Version 
Summary0014946: Suddenly start working extremely slow
DescriptionHi 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
TagsNo tags attached.
PatchNo

Relationships

related to 0001036 confirmed Severe performance problem on documents with very large number of linked frames 

Activities

rzaprianov

2017-08-11 10:16

reporter  

A5 - mirmi conf_2017.sla (577,244 bytes)

ale

2017-08-13 09:15

manager   ~0044312

Last edited: 2017-08-13 09:21

View 2 revisions

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.

ale

2017-08-13 09:20

manager   ~0044313

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...

rzaprianov

2017-08-13 15:27

reporter   ~0044315

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.

tim_occ

2017-08-13 16:07

reporter   ~0044316

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)

ale

2017-08-13 16:41

manager   ~0044317

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.

rzaprianov

2017-08-13 16:46

reporter   ~0044318

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

A5 - mirmi conf_2017_V.1.4.sla (933,098 bytes)

ale

2017-08-13 17:14

manager   ~0044319

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.

rzaprianov

2017-08-13 19:19

reporter   ~0044320

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 .....

PeterBenedek

2017-08-13 20:52

developer   ~0044321

Last edited: 2017-08-13 20:52

View 2 revisions

Perhaps related: 0014467 ?
I don't know.

rzaprianov

2017-08-13 21:36

reporter   ~0044322

No, I don't think so the difference is in the file size. His file is 20 MB, my file is 508Kb.

rzaprianov

2017-08-13 21:37

reporter   ~0044323

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.

ale

2017-08-14 05:49

manager   ~0044324

@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.

Issue History

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 View Revisions
2017-08-13 15:27 rzaprianov Note Added: 0044315
2017-08-13 16:07 tim_occ 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 View Revisions
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