View Issue Details

IDProjectCategoryView StatusLast Update
0012825ScribusStory Editor / Text Framespublic2017-06-22 05:20
ReporterJLuc Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status confirmedResolutionopen 
PlatformLinuxOSUbuntuOS Version14.04
Product Version1.5.0svn 
Target Version1.5.4Fixed in Version 
Summary0012825: Severe performance issue with layers having special blend modes
DescriptionOn a modern computer, with a 30 pages document having only one text frame, on the first page, scribus is very slow at editing text in wysiwyg mode.

When i type 10 glyphs without waiting between each keystrike, it takes 3 seconds for scribus to update the display, and the fan fans as if it was trying to break a sha256 coded password.

There are 2 layers in this document.
One of the layer is empty.
If i delete this empty layer, text editing becomes brisk and lively.

When the document is only 1 page long, then there is no issue neither.

EDIT : this happens when some special blend mode is applied to the layer
Steps To ReproduceOpen uploded document slow.sla
Try editing text in first page text frame
See how slow.

Open layers window
Delete "empty" layer (not "main" one)
Try editing text in first page text frame
See how brisk.

Additional InformationCategory for this bug is "story editor" might not be the most appropriate.

I'm very glad to have discovered that scribus is not slow because of linked text frames, but because of layers - at least on this document. Because i can do without layers, but i cant do without linked text frames.
Tagslayers
PatchNo

Relationships

related to 0001036 confirmed Severe performance problem on documents with very large number of linked frames 
related to 0014032 closedjghali Severe performance problem on documents with 8 linked frames 
child of 0002438 acknowledged Metabug: Cases of extreme memory use 
child of 0003838 acknowledged Metabug: Scribus layers 

Activities

FirasH

2014-11-24 17:10

developer   ~0034242

Confirmed with 1.5.0.svn (19638).
It's much slower before deleting the empty layer.

JLuc

2015-03-31 12:32

developer   ~0034788

elmargik came on irc and said :
"
Somehow performance is getting very low :(
[...snip...]
I have 1 layer for images and one layer for text :/
so this makes scribus slow?
"
and later on :
"
ok i merged all to 1 layer
and it is faster now
"

JLuc

2015-03-31 13:07

developer   ~0034789

ale mentions these Qtcreator profiling tools : http://doc.qt.digia.com/qtcreator-2.4/creator-cache-profiler.html

JLuc

2015-04-11 18:29

developer   ~0034888

Last edited: 2015-04-12 07:46

View 5 revisions

I used valgrind and kcachegrind to study what could origin this slowdown. I didnt know these tools so i'm not sure of my clues.

[Edit] Test path was :
- launch scribus15svn with debug data,
- open slow.sla, enter edit mode on text frame,
- type about 60 letters (insert glyph) in about 5 places of the text (click to change place).
- Close scribus without saving doc.[/Edit]

It found that it could be ScPainter::endLayer() that eats up to 82% CPU as soon as there is more than one layer. (scribus/scpainter.cpp L105)

Within scPainter::endLayer, it seems to be the call to cairo_paint_with_alpha that requires all this CPU power.

Maybe it would be possible to not call cairo_paint_with_alpha so frequently within endLayer function ?

[Edit]
endLayer() function is called many times more than stricly required by my edits.
Maybe it would be possible to not call endlayer so frequently ?
(When no display-change causing edit has happened, enLayer should not be called.)

Or maybe cairo_paint_with_alpha could be called with less CPU expensive parameters, in circumstances when it's possible ? Or replaced with some other less CPU expensive function, in circumstances when it's possible ?
[/Edit]

JLuc

2015-04-12 08:15

developer   ~0034893

Last edited: 2015-04-12 08:16

View 2 revisions

AMOF cairo_paint_with_alpha() is similar to cairo_paint(), but the drawing is faded out using the alpha value. cairo_paint() only has one arg since it doesnt need alpha arg. (see see http://www.cairographics.org/manual/cairo-cairo-t.html#cairo-paint)

So it's possible to replace all calls to cairo_paint_with_alpha() with cairo_paint() when alpha=1, that is : most of the time.

I tested in ::endLayer() and that brings an obvious speed improvement.

In scribus code, there are 27 places where cairo_paint_with_alpha is called.
In 12 of these places, there is no need fot the 2nd parameter since its constant "cairo_paint_with_alpha(cr, 1.0);"

I suggest the following code changes :

a) to replace all "cairo_paint_with_alpha(cr, 1.0);"
with plain "cairo_paint(cr);"
b) This could be emebeded in a scribus_paint(cr) function.

c) for all other calls (where alpha arg is not a constant), i suggest to test whether alpha is 1 and in case it is 1.0, would call plain and speedy cairo_paint(), and in case its not 1.0, would call cairo_paint_with_alpha
if (alpha==1)
   cairo_paint(cr);
else
   cairo_paint_with_alpha (cr, alpha);

d) this test could be embeded in a scribus_paint_with_alpha (cr, aplha) function.

I could provide a patch in case you agree with some of these proposals.

Kunda

2015-04-29 01:29

manager   ~0034981

assigning to 1.5.1 since it merits keeping an eye on this

JLuc

2015-05-07 21:55

developer   ~0035065

Not so simple.

I have to valgrind my proposal precisely
because my feelings of speed improvements are contradicted by the source of cairo_paint_with_alpha(void *cr, double alpha) that does the test itself allready :
if (CAIRO_ALPHA_IS_OPAQUE (alpha))
         return _cairo_gstate_paint (cr->gstate);

JLuc

2015-05-18 16:44

developer   ~0035158

Precisely, for each "real character" like 'a' or 'z', the keystrike triggers a burst of 6 calls to endLayer.

Here are the functions that triggers these calls :
- 1) Canvas::DrawPageGridSub
- 2) Canvas::drawContents
- 3) Canvas::DrawPageGridSub
- 4) Canvas::DrawPageGridSub
- 5) Canvas::DrawPageGridSub
- 6) Canvas::drawContents

Its different for CTRL or SHIFT key that only trigger 2 or 3 calls.

Beside, Im' not sure if my valgrind undestanding is correct, because scribus still takes a long time to digest long bursts of speedy keystroke, even if i call cairo_paint only at the start of each burst of keystroke.

Fahad

2016-10-30 06:36

developer   ~0042226

@JLuc is there any update on this from your side?

JLuc

2016-10-30 08:07

developer  

slow.sla (44,048 bytes)

JLuc

2016-10-30 08:08

developer  

slow not.sla (34,891 bytes)

JLuc

2016-10-30 08:13

developer   ~0042228

I've tested once again, with revision 21106 and i have different results with 2 very similar files.
- 'slow.sla' is verrrrrry slow to edit.
- 'slow not.sla' is not soooo slow to edit.

I've uploaded both of these files.
Only differences i can spot are that slow.sla has a few styles being defined, since it comes from a real book project and has a long edit log.
Other difference is that 'slow not' has no color for border display.

Btw test computer is a Intel® Core™ i7-3632QM CPU @ 2.20GHz × 8 cores and 16Go RAM

cbradney

2016-10-30 16:57

administrator   ~0042230

Fahad... its slow (slow.sla) , even in CTL. Removing the empty layer fixes the speed issues immediately.

PeterBenedek

2016-10-31 12:42

developer   ~0042241

Last edited: 2016-10-31 12:50

View 3 revisions

"main" layer turned on "Blend mode": Darken mode

"main" layer: enabled Darken mode (Blend mode == Darken mode) --> edit slow

"main" layer: disabled Darken mode (Blend mode == Normal) --> edit fast

JLuc

2016-10-31 18:39

developer   ~0042247

@peterbenedek I dont understand at all what you are writing about.

What are those "darken" or "blend" mode and where should they be turned on or off ?

cbradney

2016-10-31 18:58

administrator   ~0042248

JLuc.. in the layers palette.. select the main later and turn off the blend mode, ie set to normal.

yes it is much better like that.

JLuc

2016-10-31 21:17

developer   ~0042252

OK.
I confirm it becomes much better without that blend mode !

So this issue is specifically related to the special blend modes.

eudoxos

2017-06-22 05:20

reporter   ~0044074

In a 80+ page document where the "multiple"-blended layer was actually only used on a few pages, performance was affected in the whole document no matter which pages were visible. Thus a partial but easy optimization would be to check object count for special-blended layers when rendering a particular page: if zero, skip rendering of that layer on that page. Just an idea FWIW.

Issue History

Date Modified Username Field Change
2014-11-20 16:55 JLuc New Issue
2014-11-20 16:55 JLuc File Added: slow.sla
2014-11-20 16:56 JLuc Description Updated View Revisions
2014-11-20 16:56 JLuc Steps to Reproduce Updated View Revisions
2014-11-20 17:04 JLuc Additional Information Updated View Revisions
2014-11-20 22:40 JLuc Description Updated View Revisions
2014-11-22 09:35 JLuc Description Updated View Revisions
2014-11-24 17:10 FirasH Note Added: 0034242
2014-11-24 17:10 FirasH Status new => confirmed
2015-03-31 12:32 JLuc Note Added: 0034788
2015-03-31 13:07 JLuc Note Added: 0034789
2015-04-11 18:29 JLuc Note Added: 0034888
2015-04-12 07:44 JLuc Note Edited: 0034888 View Revisions
2015-04-12 07:44 JLuc Note Edited: 0034888 View Revisions
2015-04-12 07:45 JLuc Note Edited: 0034888 View Revisions
2015-04-12 07:46 JLuc Note Edited: 0034888 View Revisions
2015-04-12 08:15 JLuc Note Added: 0034893
2015-04-12 08:16 JLuc Note Edited: 0034893 View Revisions
2015-04-29 01:29 Kunda Note Added: 0034981
2015-04-29 01:29 Kunda Target Version => 1.5.1
2015-04-29 01:30 Kunda Relationship added child of 0002438
2015-05-07 21:55 JLuc Note Added: 0035065
2015-05-18 16:44 JLuc Note Added: 0035158
2015-09-17 20:08 Kunda Category Story Editor / Text Frames => Story Ed/Txt Frames
2015-09-17 20:12 Kunda Category Story Ed/Txt Frames => Story Editor / Text Frames
2016-01-23 17:16 cbradney Target Version 1.5.1 => 1.5.3
2016-05-06 19:48 JLuc Relationship added related to 0014032
2016-10-30 06:36 Fahad Note Added: 0042226
2016-10-30 08:07 JLuc File Deleted: slow.sla
2016-10-30 08:07 JLuc File Added: slow.sla
2016-10-30 08:08 JLuc File Added: slow not.sla
2016-10-30 08:13 JLuc Note Added: 0042228
2016-10-30 16:57 cbradney Note Added: 0042230
2016-10-31 08:47 JLuc Relationship added child of 0003838
2016-10-31 12:42 PeterBenedek Note Added: 0042241
2016-10-31 12:44 PeterBenedek Note Edited: 0042241 View Revisions
2016-10-31 12:50 PeterBenedek Note Edited: 0042241 View Revisions
2016-10-31 18:39 JLuc Note Added: 0042247
2016-10-31 18:58 cbradney Note Added: 0042248
2016-10-31 21:17 JLuc Note Added: 0042252
2016-10-31 21:18 JLuc Summary Severe performance issue with layers. => Severe performance issue with layers having special blend modes
2016-10-31 21:18 JLuc Description Updated View Revisions
2016-11-17 11:24 Kunda Relationship added related to 0001036
2016-12-06 12:30 Kunda Tag Attached: layers
2016-12-08 22:04 Kunda Target Version 1.5.3 => 1.5.4
2017-06-22 05:20 eudoxos Note Added: 0044074