Bug 49897 - freeze / synchronous layout post .doc load
Summary: freeze / synchronous layout post .doc load
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.3 release
Hardware: Other All
: medium major
Assignee: Not Assigned
Whiteboard: target:3.6.0 target:3.5.4
Depends on:
Reported: 2012-05-14 03:23 UTC by Michael Meeks
Modified: 2012-05-14 09:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

if we import no ww8 fields, don't force layout post load (2.24 KB, patch)
2012-05-14 04:14 UTC, Michael Meeks

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2012-05-14 03:23:56 UTC
The document https://bugs.freedesktop.org/attachment.cgi?id=58807 linked from bug#47644 when loaded (please use master for the OLE2 speedups), then proceeds to have a 15 second hang while it is doing layout.

Since we're just looking at the first page when that is done, it makes you wonder: why are we blocking the user this long, can't we do an incremental layout of some kind ?

I attach a callgrind profile of the startup + load (startup vanishes into the random noise).
Comment 2 Michael Meeks 2012-05-14 03:31:28 UTC
Seems most of the aggravation (~75%+ of the time) comes from:

    if( pWrtShell->GetDoc()->IsUpdateExpFld() )
        SET_CURR_SHELL( pWrtShell );
        pWrtShell->GetDoc()->UpdateFlds(NULL, false);
        pWrtShell->GetDoc()->SetUpdateExpFldStat( sal_False );

So - I guess, being able to defer more of that, to not do it synchronously would be rather nice ;-)
Comment 3 Michael Meeks 2012-05-14 03:52:04 UTC
For a complete start, parse, layout cycle - without the sync. layout I get a 6 second load, with it I get a 24 second load.

Hopefully we hit that path reasonably infrequently but even so; surely many kinds of field we can update asynchronously as the data changes [ though I guess that can trigger re-layouts itself but we must have this problem already ].
Comment 4 Michael Meeks 2012-05-14 04:14:46 UTC
Created attachment 61603 [details]
if we import no ww8 fields, don't force layout post load

So - the attached is a pretty grisly one - since it's specific to ww8 - whereas we have the same problem here all across the filter code.

Ideally we should maintain a count of the number of each type of field we actually have in the writer core, and be able to know which of these we actually need to force this CalcLayout for in SwView - I suspect few require this.

OTOH, this captures the 6 second load of that slow .doc document, and I've tested that it does the sync. layout if you do have fields there.

Thoughts appreciated.
Comment 5 Michael Meeks 2012-05-14 04:38:24 UTC
Caolan, Cedric - thoughts ? [ and for -3-5 ? ]
Comment 6 Not Assigned 2012-05-14 08:13:32 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":


Resolves: fdo#49897 add+use SwDoc::containsUpdatableFields
Comment 7 Caolán McNamara 2012-05-14 08:16:32 UTC
How about the above commit ? More generic across filters, dunno if it makes sense to burrow down into the updateable fields, most are updateable I guess.

Most big docs are going to have a page-count/page-number fields at least so this mightn't be massively useful in the general case, but *looks* on the face of it safe anyway ?
Comment 8 Not Assigned 2012-05-14 09:31:45 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":


Resolves: fdo#49897 add+use SwDoc::containsUpdatableFields

It will be available in LibreOffice 3.5.4.
Comment 9 Michael Meeks 2012-05-14 09:34:25 UTC
Lovely, gave it a whirl; yes it's a shame that larger docs are more likely to have eg. page-number fields, I guess we need to do more work in future to make them update pleasantly and asynchronously as the document is laid out - nevertheless, simple documents big and small should load a little faster.

Pushed to -3-5 - thanks ! :-)