Bug 45820 - insanely slow wmf import (complex clipping and basegfx::tools::findCuts)
Summary: insanely slow wmf import (complex clipping and basegfx::tools::findCuts)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: interoperability target:5.4.0
Keywords: filter:emf, perf
: 45122 114197 (view as bug list)
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2012-02-09 02:33 UTC by Caolán McNamara
Modified: 2018-06-16 15:05 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
sample wmf (484.76 KB, application/x-bzip)
2012-04-26 02:17 UTC, Caolán McNamara
Details
another example (2.18 MB, image/x-wmf)
2013-10-08 14:39 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Caolán McNamara 2012-02-09 02:33:05 UTC
the attached .wmf is incredibly slow to load, seems to spend most of its time in basegfx::tools::findCuts in trying to figure out a complicated clipping path
Comment 1 Caolán McNamara 2012-02-09 02:35:28 UTC
caolanm->thorsten: any good ideas about how to make this not so awesomely slow ?

gimp/libwmf struggle a bit with it too, but are a few orders of magnitude faster nevertheless
Comment 2 Thorsten Behrens (CIB) 2012-02-10 01:55:27 UTC
(In reply to comment #1)
> gimp/libwmf struggle a bit with it too, but are a few orders of magnitude 
> faster nevertheless

yeah, that's this "let's flatten down all clips to Region" or somesuch madness going on, that's IMO from long-gone ancient times when Win16 was slow/inable to process polygonal clips.

I had once improved the easy case (rectangular clips), will look into this one if there's a similarly easy quick fix - beyond that, the right way forward is to more or less import WMF actions as-is, to semantically equivalent SVM - or even better, get rid of this intermediate completely & render WMF, like we do for EMF+, and for SVG. ;)
Comment 3 Horcrux7 2012-04-18 09:02:30 UTC
(In reply to comment #0)
> the attached .wmf is incredibly slow to load, seems to spend most of its time
> in basegfx::tools::findCuts in trying to figure out a complicated clipping path

Where is the attachment? Can you reattached it to bug ticket?
Comment 4 Caolán McNamara 2012-04-26 02:17:58 UTC
Created attachment 60604 [details]
sample wmf

Sorry for a delay, I had extracted the wmf from a mega-run over all fdo/ooo bugzilla .ppts files and couldn't find the exact one again to re-extract it :-)

Found it again as the wmf embedded in the bugdoc ppt from https://issues.apache.org/ooo/show_bug.cgi?id=55877

Now attached standalone (compressed as it doesn't fit into fdo's size limit otherwise. Which is probably what happened the last time too, except I failed to see it had been rejected)
Comment 5 Marco 2013-01-21 13:47:38 UTC
I can confirm this bug on platform LO 4 RC1, Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)

See also bug 41522, is this a similar issue?
Comment 6 Marco 2013-01-21 13:48:57 UTC
(In reply to comment #5)
> I can confirm this bug on platform LO 4 RC1, Version 4.0.0.1 (Build ID:
> 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)
> 
> See also bug 41522, is this a similar issue?

Edit: the correct number is bug 45122. Ignore the typo in the line above.
Comment 7 Thorsten Behrens (CIB) 2013-09-12 16:14:49 UTC
Apologies for not having gotten around fixing this bug yet; unfortunately in future I'll have even less time at my disposal for this, so I'm freeing up ownership for other volunteers to take over.
Comment 8 Caolán McNamara 2013-10-08 14:39:14 UTC
Created attachment 87291 [details]
another example
Comment 9 QA Administrators 2015-04-01 14:42:46 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2015-04-24 17:38:51 UTC
Confirmed that trying to open attachment 60604 [details] (not by insert, but dragging to LibO) takes a couple of minutes.

Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64)
Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50
Locale: fi_FI
Comment 11 Andras Timar 2015-06-27 17:01:49 UTC
*** Bug 45122 has been marked as a duplicate of this bug. ***
Comment 12 QA Administrators 2016-09-20 10:11:56 UTC Comment hidden (obsolete)
Comment 13 MM 2016-10-10 19:34:52 UTC
Confirmed with v5.2.2.2 under ubuntu 16.04 x64.
Comment 14 Commit Notification 2017-01-05 20:37:15 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfe33fcd20d97e34ba7b7926a5a0c9a93e0e9960

Related: tdf#45820 polygon clipping during wmf load is ultra slow

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Volga 2017-01-23 03:06:19 UTC
Is it possible to backport to 5.3.0?
Comment 16 Caolán McNamara 2017-01-23 17:09:24 UTC
above commit is only related to this, doesn't fix it, but I personally feel its the right direction to go, but needs investigation to see why, when enabled, there is visual differences
Comment 17 Buovjaga 2017-12-09 22:23:58 UTC
*** Bug 114197 has been marked as a duplicate of this bug. ***
Comment 18 Roman Kuznetsov 2018-06-16 15:05:58 UTC
example opens 1.30 min in

Version: 6.0.4.2 (x64)
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: ru-RU (ru_RU); Calc: CL