View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012825 | Scribus | Story Editor / Text Frames | public | 2014-11-20 16:55 | 2017-06-22 05:20 |
| Reporter | JLuc | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | ||
| Platform | Linux | OS | Ubuntu | OS Version | 14.04 |
| Product Version | 1.5.0svn | ||||
| Target Version | 1.5.4 | ||||
| Summary | 0012825: Severe performance issue with layers having special blend modes | ||||
| Description | On 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 Reproduce | Open 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 Information | Category 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. | ||||
| Tags | layers | ||||
| Patch | No | ||||
| related to | 0001036 | confirmed | Severe performance problem on documents with very large number of linked frames | |
| related to | 0014032 | closed | jghali | 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 |
|
|
Confirmed with 1.5.0.svn (19638). It's much slower before deleting the empty layer. |
|
|
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 " |
|
|
ale mentions these Qtcreator profiling tools : http://doc.qt.digia.com/qtcreator-2.4/creator-cache-profiler.html |
|
|
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] |
|
|
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. |
|
|
assigning to 1.5.1 since it merits keeping an eye on this |
|
|
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);
|
|
|
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. |
|
|
@JLuc is there any update on this from your side? |
|
|
|
|
|
|
|
|
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 |
|
|
Fahad... its slow (slow.sla) , even in CTL. Removing the empty layer fixes the speed issues immediately. |
|
|
"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 |
|
|
@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 ? |
|
|
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. |
|
|
OK. I confirm it becomes much better without that blend mode ! So this issue is specifically related to the special blend modes. |
|
|
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. |
| 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 | |
| 2014-11-20 16:56 | JLuc | Steps to Reproduce Updated | |
| 2014-11-20 17:04 | JLuc | Additional Information Updated | |
| 2014-11-20 22:40 | JLuc | Description Updated | |
| 2014-11-22 09:35 | JLuc | Description Updated | |
| 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 | |
| 2015-04-12 07:44 | JLuc | Note Edited: 0034888 | |
| 2015-04-12 07:45 | JLuc | Note Edited: 0034888 | |
| 2015-04-12 07:46 | JLuc | Note Edited: 0034888 | |
| 2015-04-12 08:15 | JLuc | Note Added: 0034893 | |
| 2015-04-12 08:16 | JLuc | Note Edited: 0034893 | |
| 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 | |
| 2016-10-31 12:50 | PeterBenedek | Note Edited: 0042241 | |
| 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 | |
| 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 |
